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PREFACE 

This  paper  provides  user  interface  lessons  learned  for  various  Integrated 
Maintenance  Information  System  (IMIS)  applications  developed  for  the  Logistics 
Research  Division.  The  primary  focus  of  division  projects  has  been  for  hardware, 
software,  and  user  interfaces  in  support  of  IMIS  Portable  Maintenance  Aids.  Work 
contributing  to  user  interface  lessons  learned  was  performed  by  a  combination  of 
organizations  supporting  several  demonstration  IMIS  systems.  Special  thanks  is 
extended  to  Applied  Science  Associates,  Inc.,  Computer  Sciences  Corporation,  RJO 
Enterprises,  Inc.,  NCI  Information  Systems,  Inc.,  General  Dynamics  Electronics  Systems, 
Lockheed  Fort  Worth,  and  Systems  Research  Laboratories,  Inc.  Human  factors  expertise 
was  sponsored  by  the  University  of  Dayton  Research  Institute  under  Contract  No. 
DLA900-88-D-03 93 . 
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IMIS  FIELD  TESTED  USER  INTERFACE  LESSONS  LEARNED 


INTRODUCTION 

The  intent  of  this  report  is  to  identify  the  major  strengths  and  weaknesses  that 
have  resulted  from  designing  user  interfaces  for  maintenance-aiding  devices  and  other 
systems  relevant  to  the  Integrated  Maintenance  Information  Systems  (IMIS)  at  Armstrong 
Laboratory’s  Logistics  Research  Division  (AL/HRG).  In  this  report,  a  chronology  of  user 
interface  design  efforts  and  subsequent  design  issues  are  defined  in  terms  of  effective  and 
ineffective  solutions.  The  chronology  itemizes  design  decisions  made,  the  justification 
for  those  decisions,  and  recommendations  for  future  efforts.  This  format  allows  the 
recommendations  to  be  applied  to  other  similar  development  efforts.  The  chronology  is 
presented  in  terms  of  the  primary  research  programs  conducted  at  the  laboratory  up  to  and 
including  future  full  production  implementations  of  IMIS  systems. 

This  report  provides  an  overview  of  relevant  literature  and  general  analyses  of 
study  conclusions  pertaining  to  IMIS  development  efforts.  Several  previously  written 
documents  were  extensively  used  in  compiling  information  for  this  report  (Quill,  1992a, 
1992b;  Quill,  Wynkoop,  &  Wampler,  1992;  Thomas  &  Clay,  1988).  For  additional  detail 
concerning  information  presented  on  individual  studies,  refer  to  the  references  cited  in 
this  document. 

GOAL  OF  AN  INTEGRATED  MAINTENANCE  INFORMATION  SYSTEM 

(IMIS) 

The  overall  goal  of  an  IMIS  is  to  “provide  the  maintenance  technician  with  the 
capability  to  access  all  of  the  technical  information  (interactive  electronic  technical 
manuals,  interactive  diagnostics  instructions,  work  orders,  supply  availability  and 
ordering,  historical  data,  training  material,  etc.)  required  to  maintain  aircraft  via  a  single, 
integrated  system,  regardless  of  the  source  of  that  information”  (Johnson,  1993,  p.  1). 
AL/HRG  has  instituted  an  iterative  design  process  which  comprises  three  phases.  Tasks 
accomplished  within  each  of  these  phases  have  resulted  in  an  iterative  improvement  cycle 
for  user  interface  design.  Each  phase  also  includes  major  hardware  and  software  design 
goals,  all  of  which  were  intended  to  prove  the  “concept”  of  an  integrated  computerized 
maintenance-aiding  system. 


EVOLUTION  OF  IMIS 

The  IMIS  development  effort  has  incorporated  a  multiphased  approach  (General 
Dynamics  Electronics  Division,  1990;  Link,  Murphy,  Carlson,  Thomas,  Brown,  &  Joyce, 
1990;  Quill,  Wynkoop  &  Wampler,  1992;  Thomas  &  Clay,  1988).  Phase  I  (which  was 
conducted  from  1982  to  1987)  consisted  of  two  intermediate  shop  field  tests  (i.e.,  two 
design  goals).  The  Computerized  Maintenance  Aiding  Systems  (CMAS  I  and  CM  AS  II) 
developed  for  this  effort  introduced  the  basic  technology  required  for  presenting  technical 
order  data  on  an  automated  system  (see  Table  1). 
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TABLE  1.  IMIS  Phases 


PHASES 

DESIGN  GOALS 

Phase  I 

CMASI 

CMAS  II 

Phase  II 

Portable  Computer-Maintenance-Aiding  System 

I  (PCMAS  I) 

Portable  Computer-Maintenance-Aiding  System 

II  (PCMAS  II) 

F/A-18  Portable  Maintenance  Aid  (PMA) 

Phase  III 

General  Dynamics  Electronics  Systems  (GDES) 

F-16IMIS 

Interactive  Electronic  Technical  Manual 
(IETM)  Presentation  System  (IPS) 

From  1986  to  1992,  Phase  II  expanded  the  scope  of  the  IMIS  effort.  During  this 
phase,  field  tests  were  conducted  in  a  flight  line  environment.  The  Portable  Computer 
Maintenance  Aiding  Systems  (PCMAS  I,  PCMAS  II,  and  F/A-18  Portable  Maintenance 
Aid  [PMA])  developed  for  this  environment  required  automated  diagnostics;  extended 
automated  technical  data  presentation;  development  of  technical  data  interchange 
standards;  and  preliminary  examination  of  the  automation  of  functions,  such  as  ordering 
parts. 

From  1988  to  1994,  Phase  III  provided  a  full-scale  IMIS  demonstration  system  for 
accessing  all  information  required  for  a  technician  to  perform  maintenance  activities  at 
the  job  site  (e.g.,  Core  Automated  Maintenance  System  [CAMS]  interface).  The  General 
Dynamics  Electronics  Systems  (GDES)  IMIS  system  was  developed  during  this  phase. 
Additionally,  the  laboratory  developed  an  in-house  application,  similar  to  the  GDES 
IMIS  system.  This  Interactive  Electronic  Technical  Manual  (IETM)  Presentation  System 
(IPS)  incorporated  many  of  the  lessons  learned  from  a  data,  software,  and  user  interface 
perspective  (only  the  user  interface  lessons  learned  are  included  in  this  document). 

USER  INTERFACES 

Throughout  the  phases  of  IMIS  development,  several  design  principles  have  been 
used  to  design  user  interfaces.  These  principles  included  flexibility,  direct  manipulation, 
error  avoidance,  and  consistency. 


2 


Flexibility 

Flexibility  in  design  allows  all  users  to  readily  move  from  one  platform  to 
another,  novice  users  to  use  step-by-step  procedures  to  accomplish  an  interface 
manipulation,  and  experienced  system  users  to  take  shortcuts  to  execute  interface  actions. 
Flexibility  in  design  includes  being  flexible  to  user  needs  and  being  flexible  in  interfacing 
to  other  system  components.  If  technological  advances  improve  the  type  of  hardware 
available,  the  user  interface  should  permit  easy  upgrade  to  the  latest  hardware  platform. 
Likewise,  if  a  new  method  of  job-aiding  becomes  available,  the  user  interface  should 
accommodate  this  upgrade  without  revising  the  entire  application. 

Direct  Manipulation 

Direct  manipulation  is  a  means  of  achieving  consistency.  Consistency  refers  to 
“an  agreement  of  logical  coherence  among  things  or  parts,  compatibility  or  agreement 
among  successive  acts,  ideas,  or  events”  (Houghton  Mifflin  Company,  1982).  A  direct 
manipulation  interface  permits  the  user  to  point  at  visual  representations  of  objects  and 
actions,  to  carry  out  tasks  rapidly,  and  to  observe  the  results  immediately  (Shneiderman, 
1992).  When  a  method  of  achieving  direct  manipulation  has  been  defined  and 
standardized  in  the  design,  many  aspects  of  consistency  in  design  are  achieved. 

Reduction  in  Errors 

Systems  that  utilize  good  direct  manipulation  methods  and  that  implement  other 
consistency  design  features  can,  as  a  result,  reduce  user  errors  (Shneiderman,  1992).  A 
simple  example  can  be  illustrated  through  a  log-out  scenario.  When  a  user  quits  a  session 
(i.e.,  logs  out),  the  system  automatically  prompts  the  user  (through  a  dialog  box)  to  save 
the  session.  Through  a  few  keypresses  (mostly  confirming  the  file  name  to  be  saved)  the 
user  can  save  the  work  or  discard  it.  Without  this  type  of  direct  manipulation  prompt, 
errors  of  omission  could  be  made  (e.g.,  the  user  could  quit  without  remembering  to  save) 
or  errors  of  commission  could  be  made  (e.g.,  the  user  could  inadvertently  save  the  work 
under  the  wrong  name). 


Consistency  in  Design 

Within  the  various  disciplines  associated  with  the  IMIS  development  process 
(e.g.,  user  interface  design,  software  design,  hardware  design,  and  data  development),  an 
overriding  design  principle  has  been  maintaining  consistency.  Consistency  has  played  an 
important  role  in  development  efforts,  especially  in  the  human-computer  interface 
domain,  whether  it  has  pertained  to  the  ability  to  transfer  the  technology  from  one  aircraft 
environment  to  another  or  to  the  ability  to  take  skills  and  knowledge  obtained  in  other 
situations  and  use  them  in  the  IMIS  environment.  Thus,  as  noted  in  this  report, 
consistency  —  although  normally  thought  of  as  a  user-interface  issue  —  has  played  and 
will  continue  to  play  an  important  role  in  all  aspects  of  IMIS  development,  including 
data,  software,  and  hardware  efforts. 

The  following  items  exemplify  the  importance  of  consistency  in  all  IMIS 
development  efforts. 
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•  User  Interface.  To  facilitate  their  efforts,  maintenance  technicians  should  face  the 
same  types  of  interface  widgets  as  they  move  from  their  personal,  home  computer 
to  the  IMIS  PMA  and  the  IMIS  workstation  (e.g.,  pressing  a  space  bar  checks  off 
a  checkbox).  Consistency  among  these  platforms  assists  in  minimizing  learning 
(e.g.,  transferring  training  already  attained  at  home),  performance  times,  and 
errors.  Without  consistency,  more  training  time  will  be  required  to  become 
proficient  and  perform  the  tasks.  Also,  more  errors  will  be  made  while  using  the 
system  which  will  result  in  user  frustration  during  system  use.  These  effects  will 
be  heightened  for  technicians  with  limited  computer  skills. 

•  Hardware.  The  hardware  (e.g.,  mouse,  joystick,  light  pen)  must  work 
interchangeably  whether  the  user  is  in  a  maintenance  shop,  an  expediter’s  truck, 
or  a  flight  line.  If  this  consistency  in  design  is  not  provided,  personnel  may 
become  specialized  in  the  maintenance  hardware  systems  they  can  use  and  thus 
will  be  less  able  to  transition  among  various  job  assignments. 

•  Software.  Consistency  in  software  is  closely  coupled  with  the  user  interface  but  is 
a  separate  characteristic.  As  the  underlying  software  becomes  more  consistent, 
the  functions  and  mechanisms  to  control  data,  user  interface,  diagnostics,  and  so 
forth  are  reduced  and  standardized.  Therefore,  efficiencies  in  design  time, 
development  time,  and  access  time  (e.g.,  system  response  time)  are  obtained. 

•  Data.  Consistency  in  the  format  of  data  makes  information  much  easier  to 
display,  implement,  and  modify.  Furthermore,  a  consistent  format  allows  user 
interfaces  to  take  full  advantage  of  the  structure  of  the  data  to  implement  links 
(e.g.,  hyperlinks)  to  other  pertinent  information  in  the  database. 

Design  Principles  —  Lesson  Learned 

Overall,  the  lessons  learned  for  IMIS  user  interfaces  reveal  a  tendency  to 
concentrate  on  the  design  of  hardware  user  interface  issues  (e.g.,  the  size  of  the  keys) 
rather  than  on  the  design  of  software-related  issues  (e.g.,  data,  screen  design,  etc.).  For 
example,  front-end  field  tests  are  rarely  performed  on  sample  screens,  and  state  and 
transition  diagrams  are  generally  an  afterthought  of  the  design  process.  Obtaining  user 
feedback  through  early  testing  of  software  interface  requirements  (e.g.,  using  state  and 
transition  diagram  information)  provides  concise  data  and  software  specifications. 
Functional  requirements  of  an  IMIS  system  (or  any  software  and  hardware  development 
effort)  must  be  driven  by  user  requirements  (i.e.,  requirements  obtained  and  refined 
through  data  collection,  analysis,  and  iteration).  Thus,  the  user  interface  can  be  designed 
using  actual  requirements,  available  data  tagging  schemes  (Department  of  Defense, 
1992a),  hardware  capabilities  and  constraints,  and  software  development  tools  (e.g., 
digital  graphical  user  interface  builders  and  off-the-shelf  languages).  In  this  way,  the  user 
interface  unites  and  manages  all  system  components  into  one  package  which  is  readily 
usable. 
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DOCUMENT  OVERVIEW 

The  remainder  of  this  document  is  organized  according  to  the  design  goals  for 
each  phase.  Where  applicable,  a  discussion  of  each  issue  begins  with  the  design  goal  in 
which  it  was  first  implemented  and  concludes  with  recommendations  for  future 
implementations. 


HARDWARE 
Case  Enclosure 

The  primary  hardware  goal  of  a  PMA  development  has  been  to  design  a 
lightweight,  portable,  ruggedized  computer  which  can  display  all  necessary  information 
for  aircraft  maintenance  (predominantly  targeted  for  the  flight  line  environment).  Phase  I 
activities  did  not  include  any  hardware  development. 

Phase  II 

The  goals  for  the  PCMAS  I  and  PCMAS  II  development  efforts  were  to  build  the 
portable  device  to  weigh  approximately  eight  pounds.  Ruggedization  was  only 
moderately  attempted  in  these  two  designs  because:  (1)  these  devices  were  proof-of- 
concept  efforts,  and  (2)  subsequent  efforts  (i.e.,  GDES  PMA)  were  to  address 
ruggedization  requirements.  The  primary  goal  was  to  build  lightweight,  portable  devices 
for  maintenance  aiding.  The  initial  PCMAS  designs  were  slightly  over  the  eight-pound 
weight  goal. 

However,  the  PMA  built  for  testing  on  the  F/A-l  8  aircraft  met  the  weight  goals 
set  by  the  laboratory  (under  1 0  lbs)  for  portable  aids.  Additionally,  the  device  was 
reduced  to  a  bezel-type  configuration,  under  the  assumption  that  a  PMA  smaller  in 
length,  width,  and  depth  would  be  more  widely  accepted  by  users.  However,  a  field  test 
at  Edwards  Air  Force  Base  (AFB)  (Applied  Science  Associates,  Inc.,  1990)  comparing 
several  hardware  design  configurations  demonstrated  that  technicians  prefer  a  design 
larger  than  the  F/A-l 8  PMA  design.  PMA  design  goals  important  to  technicians  include: 

•  the  ability  to  pick  up  or  set  down  the  PMA  with  one  hand; 

•  “shock  absorption”  edges  on  the  PMA  (allowing  users  to  set  down  the  PMA 
easily  and  move  it  around  once  it  is  on  the  ground); 

•  the  ability  to  hold  the  PMA  at  its  center  of  gravity  while  using  it  (this  resulted  in 
the  extended  length  of  the  Phase  III  PMA);  and 

•  the  ability  to  carry  the  PMA  with  other  work  items,  such  as  a  toolbox  (this 
resulted  in  a  strap  design). 

Given  these  design  goals  and  the  necessity  to  design  a  ruggedized  PMA,  the  case 
enclosure  designed  by  GDES  for  the  F-16  PMA  was  somewhat  different. 
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Phase  III 

The  GDES  F-16  PM  A  resulted  in  hardware  that  increased  the  height  of  the  PM  A 
to  heights  similar  to  that  of  the  PCMAS II  (e.g.,  nearly  twice  the  height  of  the  F/A-18 
PMA).  The  GDES  case  was  the  first  to  meet  the  ruggedization,  weight,  and  portability 
requirements  for  the  PMA. 

Lessons  Learned 

An  assessment  of  case  enclosure  configuration  and  materials  revealed  that  designs 
should  permit  easy  swaps  among  hardware  cases.  When  coupled  with  perpetual  upgrades 
in  computer  electronic  technology,  the  case  housing  all  the  components  is  bound  to 
change  frequently;  designs  should  accommodate  these  changes. 

Power  Switch 


Phase  II 

The  power  switch  on  both  the  PCMAS  I  and  PCMAS  II  is  a  conventional  two- 
position  toggle  switch  —  when  toggled  to  one  position,  power  is  on;  in  the  other  position, 
power  is  off. 

The  F/A-18  PMA  power  switch  is  a  momentary  push-button  that  allows  the  user 
to  manually  turn  on  the  device;  however,  the  software  is  used  to  turn  off  the  PMA.  Users 
turn  off  the  PMA  by  entering  the  menu  system  and  engaging  the  quit  sequence.  (An 
“Off’  switch  is  not  included  in  order  to  eliminate  inadvertent  system  shutdowns  —  that 
is,  accidentally  turning  off  the  system).  The  hardware  permits  a  backdoor,  manual  reset 
function  which  the  user  initiates  by  simultaneously  pushing  the  “On”  and  “Backlight” 
push-buttons.  However,  the  initial  design  offered  no  means  to  manually  turn  off  the 
system  using  the  hardware.  Later  in  the  design  process  it  became  necessary  to  design  a  . 
backdoor  means  of  turning  off  the  PMA;  therefore,  a  three-keypad-key  combination  was 
used  for  emergency  shut-off  conditions. 

Phase  III 

The  “On/Off’  switch  of  the  GDES  F-16  PMA  is  recessed  to  minimize  inadvertent 
shutdown;  however,  the  operating  system  (UNIX)  requires  a  “graceful”  shutoff.  That  is, 
shutting  down  the  system  before  executing  the  appropriate  save  functions  could  require 
the  reloading  of  data  or  could  result  in  the  loss  of  data  gathered  during  a  session. 

Final  analysis  of  the  “On/Off  ’  switch  on  the  GDES  F-16  PMA  produced  the 
following  assessment: 

Location  and  design  of  the  power  “On/Off’  switch  is  awkward.  The 
switch  is  located  on  the  right  side  of  the  box  where  users  frequently  hold 
the  PMA.  The  switch  is  a  two-position,  standard  toggle,  which  is  mostly 
(not  entirely)  recessed.  In  a  UNIX  environment,  where  inadvertent 
deactivation  of  the  PMA  can  corrupt  the  file  system,  this  design  requires 
modification.  The  switch  should  be  a  locking  toggle  switch  or  guarded 
toggle  switch,  totally  recessed.  Ideally,  it  should  be  moved  to  the  top  of 
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the  box  (away  from  connectors  which  are  frequently  accessed)  where  users 
do  not  frequently  hold  the  PMA. 

Lessons  Learned 

Neither  the  design  of  the  F/A-18  nor  the  GDES  F-16  PMA  seemed  to  address  the 
power  switch  issue  adequately.  Some  considerations  for  future  developments  include: 

•  under  normal  circumstances,  perform  graceful  shutoff  without  losing  data  (e.g., 
saving  sessions,  and  database); 

•  under  normal  circumstances,  perform  graceful  shutoff  without  damaging  the 
operating  system; 

•  under  normal  circumstances,  deter  the  user  from  intentionally  shutting  off  the 
power  prior  to  normal  shutdown  procedures;  and 

•  under  abnormal  circumstances,  permit  the  user  to  shutdown  the  system  without 
having  to  remember  awkward  keypresses. 

Connectors  —  Lessons  Learned 

In  Phases  II  and  III,  connectors  have  been  consistently  placed  on  the  top  portion 
of  the  PMA  cases.  These  connectors  typically  have  been  used  for  RS-232  connections, 
1553  connection;  Keyboard  port;  external  alternating  current  (AC)  power;  and  antennas 
for  radio  frequency  (RF)  modems.  These  connectors  are  placed  on  the  GDES  PMAs  at  a 
distance  of  0.75  to  1 .0  inch,  measured  from  center  to  center  of  the  connection.  This 
design  requirement  allows  the  connector  to  be  hooked  up  with  bare  hands  and  gloves.  No 
tools  are  required  to  remove  the  connectors  on  the  GDES  PMA.  Placement  of  connectors 
has  proven  acceptable  in  field  tests  conducted  at  Armstrong  Laboratory  (AL). 

Placement  and  separation  of  connectors  for  future  systems  should  use  the  0.75  to 
1 .0  inch  center-to-center  arrangement  from  previous  IMIS  designs.  Additionally, 
connector  hook-up  should  require  no  tools  so  that  connections  can  be  made  easily. 

Limited  Keypad 


Keypad  Key  Dynamics 

Force  and  resistance  requirements  for  the  PMA  keypad  keys  differ  from  a 
standard  keyboard  in  that:  (1)  the  ruggedization  requirements  imposed  on  the  design 
limit  the  types  of  keys  which  can  be  used,  (2)  the  use  of  arctic  gloves  imposes  slightly 
different  requirements,  and  (3)  the  actual  keypress  action  could  potentially  be  more  of  a 
push  than  a  press  (e.g.,  if  the  user  is  bending  over  and  extending  an  index  finger  to 
display  the  next  screen  of  information,  a  “push”  force  might  be  exerted  rather  than  a 
touch  or  press-type  force). 

Military  Standard  1472-D  (MIL-STD-1472D)  (Department  of  Defense,  1989) 
makes  recommendations  on  resistance  and  displacement  for  push  buttons  (other  than 
those  used  on  keyboards)  and  keyboards.  The  PMA  keypad  is  not  intended  for  “touch 
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typing,”  however,  keying  is  required.  The  MIL-STD  calls  for  keyboards  to  be  set  at  a 
minimum  resistance  of  0.9  oz  and  minimum  displacement  of  0.03  in.  Maximums  for 
these  settings  are  a  5.3-oz  resistance  and  a  0.19-in.  displacement  (Department  of  Defense, 
1989).  For  single-finger  push  buttons,  the  settings  in  MIL-STD-1472D  are  10  oz  (min.) 
and  1 1  oz  (max.)  for  resistance,  and  5/64  in.  (min.)  and  %  in.  (max.)  for  displacement. 

Key  Size 

The  question  of  the  size  of  hard  keys  and  the  inter-key  spacing  (between  two 
adjacent  keys)  was  posed  several  times  in  the  course  of  IMIS  development.  The  issue 
pertained  not  only  to  the  needs  of  a  bare-handed  technician  but  also  to  the  technician  who 
is  wearing  arctic  gloves.  Additionally,  the  findings  were  to  apply  to  the  95th  percentile 
for  Air  Force  personnel  hand  size  measurements. 

The  Human  Factor’s  literature  offered  several  suggestions  for  keytop  sizes.  The 
suggestions  were: 

1 .  The  size  of  the  top  of  the  key  should  be  designed  at  0.5  in.  for  a  bare  hand  (Alden, 
Daniels,  &  Kanarick,  1972;  Department  of  Defense,  1989),  and  a  minimum  of 
0.75  in.  for  a  hand  in  an  arctic  mitten  (Department  of  Defense,  1989). 

2.  Interkey  spacing  should  be  0.75  in.  from  keytop  center  to  keytop  (Alden,  Daniels, 
&  Kanarick,  1972)  for  a  0.5-in.  key  and  1  in.  from  keytop  center  to  keytop  center 
for  a  0.75-in.  key  (Department  of  Defense,  1989,  March  14). 

3.  The  following  criteria  should  be  considered  in  key  resistance  and  displacement 
designs  (Boff  &  Lincoln,  1988);  however,  in  general,  force  and  displacement  have 
minimal  effects  on  keying  speed  and  error  rate  performance: 

•  Reduced  key  travel  (the  amount  of  depression)  is  preferred  for  most 
applications. 

•  Increased  key  resistance  is  preferred  for  most  applications. 


Phase  II.  The  PCMAS  I  keypad  is  composed  of  25  keys.  The  keys,  white 
characters  on  a  black  background,  consist  of  FI  through  F8,  0  through  9,  Back  Space, 
Enter,  four  directional  arrow  keys,  and  Select. 

The  PCMAS  II  keypad  includes  32  keys.  In  contrast  with  PCMAS  I,  the  keys  are 
black  characters  on  a  white  background  (see  Fig.  1).  Similar  to  PCMAS  I,  the  keys 
consist  of  0  through  9,  Erase  (ERA),  Enter  (ENT),  Next  (NXT),  Back  (BCK),  Return 
(RTN),  More/Less  (M/L),  Information  (INF),  Option  (OPT),  Table  of  Contents  (TOC), 
Control  (CNT),  three  blank  keys,  eight  directional  arrow  keys,  and  Select  (SEL). 

The  F/A-18  PMA  keypad  design  imitates  a  bezel-type  layout  (used  in  most 
aircraft  multifunction  displays).  The  bezel-type  layout  is  based  on  a  menu-driven 
interface;  the  menus  are  accessed  by  depressing  hard  keys  adjacent  to  each  edge  of  the 
screen. 
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Figure  1 
PCMAS II 
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Although  the  hard  keys  allow  menus  and  function  buttons  to  be  accessed  on  all 
sides  of  the  screen,  the  interface  was  designed  to  provide  menus  and  function  buttons 
adjacent  only  to  the  hard  keys  at  the  top  and  bottom  of  the  screen. 

The  bezel-type  design  resulted  in  the  configuration  shown  in  Fig.  2.  Thirty  two 
keys  are  dedicated  to  functions  such  as  cursor  movement,  numeric  entry,  programmable 
soft  keys,  navigation,  and  screen  manipulation  (e.g.,  menu  activation).  Additionally,  this 
aid  includes  a  knurled  thumb  knob  for  control  of  cursor  movement.  Each  key  was 
designed  and  built  to  be  0.75  in.  high  and  0.75  in.  wide,  with  0.25  in.  between  keys.  The 
only  exception  was  the  primary  “NEXT”  key  which  was  at  least  two  times  the  height  of 
the  other  keys  (width  was  the  same). 

Phase  III.  Due  to  flight  line  maintenance  requirements,  a  membrane-type  keypad 
was  specified  for  the  Phase  III  PMA.  Specifications  for  force  and  resistance  for 
membrane  keypads  were  difficult  obtain.  As  a  compromise  between  the  push  button  and 
keyboard  specifications  outlined  by  MIL-STD-1472D,  a  10-oz  resistance  and  0.1 -in. 
displacement  were  recommended  for  usability  testing  on  the  GDES  PMAs  (see  Fig.  3). 
Heuristic  evaluation  of  the  GDES  keypad  resulted  in  several  global  comments  including: 

•  The  bubble-dome-type  keys  used  on  the  PMA  do  not  always  activate  when 
pressed.  Unlike  standard  keyboard  keys,  the  keys  on  the  PMA  can  be  depressed 
but,  if  “contacts”  are  not  made,  a  keypress  event  is  not  initiated.  Contacts  are  not 
made  unless  the  key  is  pressed  directly  in  the  center. 

•  The  force  required  to  depress  PMA  keys  is  too  high.  Resistance  should  be 
lowered  so  that  keypresses  can  be  made  more  easily. 

Key  Color  and  Lighting 

The  PMA  was  designed  for  use  in  a  variety  of  conditions,  including  both  day  and 
night  situations.  To  assist  in  visibility  at  night,  the  screen  was  designed  on  PCMAS  II, 
the  F/A-18  (Phases  II),  and  GDES  PMAs  (Phase  III)  with  a  backlight.  In  response  to  a 
question  concerning  the  visibility  of  the  keypad  keys  at  night,  a  usability  test,  conducted 
at  AL/HRG,  compared  several  different  keypads.  This  test  determined  that  in  very  low- 
light  situations  (the  only  light  source  was  the  PMA  screen  backlight)  the  PMA  keypads  as 
designed  at  the  laboratory  were  not  visible.  However,  when  the  PMA  screen  was  tilted  at 
an  angle  less  than  180  degrees  with  respect  to  the  keypad,  the  keypad  key  lettering 
became  visible.  In  this  configuration,  black  keys  with  reflective  or  luminescent  lettering 
were  most  readable  at  low-light  levels.  Consequently,  the  screen  and  keypads  should  be 
capable  of  being  positioned  at  an  angle  between  90°  and  180°  with  respect  to  each  other. 

Illumination  of  the  keys  on  the  keypad  has  been  carefully  considered  in  PMA 
design.  However,  illuminating  the  keys  would  utilize  too  much  DC  power.  Therefore, 
setting  the  keypad  and  screen  at  an  appropriate  angle  is  a  more  effective  solution. 
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Figure  2 
F/A-18  PMA 
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Figure  3 
GDES  PMA 
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Lessons  Learned 

A  final  analysis  of  keypad  dynamics,  key  size,  key  color,  and  key  configuration 
confirmed  that  standard  QWERTY-arranged  keyboards  would  be  the  most  cost  effective 
for  maintenance  applications.  Each  time  a  new  hardware  or  software  component  is  added 
to  an  integrated  maintenance  system,  customized  keypads  must  be  re-evaluated  for  their 
effectiveness  with  respect  to  the  new  component.  Thus,  this  seemingly  minor  piece  of 
hardware  quickly  becomes  a  bottleneck  in  system  upgrades  and  modifications  (for  both 
software  and  hardware  integration).  Therefore,  although  standard  keyboard  arrangements 
(i.e.,  QWERTY  arrangements)  must  still  accommodate  the  rugged  environment  posed  in 
flight  line  maintenance,  they  are  still  logistically  easier  to  accommodate.  That  is,  even 
though  standard  keyboards  may  not  withstand  the  environmental  stressors  imposed  on  the 
flight  line,  they  may  be  significantly  easier  to  replace  than  customized  keypads.  When 
standard  keyboards  are  used,  the  QWERTY  or  Sholes  arrangement  should  be  used  over 
an  alphabetical  arrangement  (Hirsch,  1970;  Kinkead,  1975;  Michaels,  1971;  Norman  & 
Fisher,  1982). 


Cursor  and  Pointer  Controls 

During  the  course  of  IMIS  development,  questions  have  been  raised  concerning 
cursor  movement  and  the  various  methods  available  to  move  the  cursor. 

Phase  II 

The  F/A-l  8  PMA  provides  arrow  keys  and  a  thumb  knob,  both  of  which  the 
technician  can  use  to  move  the  cursor.  Both  methods  produce  the  same  type  of  cursor 
movement  (e.g.,  the  arrow  “up”  button  and  the  “up”  thumb  knob  movement  move  the 
cursor  up  one  selectable  item);  however,  several  factors  (in  relation  to  the  task  of  moving 
the  arrow  keys  versus  thumb  knob)  still  require  further  investigation.  To  study  this 
situation,  criteria  for  the  tasking,  and  mechanisms  to  study  these  criteria  were  needed. 
These  criteria  and  mechanisms  were  provided  to  two  Air  Force  Institute  of  Technology 
(AFIT)  students  and  their  Armstrong  Laboratory  thesis  monitor  to  further  IMIS 
development  in  the  area  of  cursor  movement  (Streff  &  Gundel,  1992). 

The  criteria  for  the  tasking  focuses  on  two  key  issues:  (1)  which  input  device  is 
better  overall,  and  (2)  which  input  device  is  better  for  various  applications  within  the 
tasks.  The  task  itself  is  not  as  important  as  the  applications  or  uses  required  for  the  task; 
therefore,  the  mechanisms  chosen  to  study  these  criteria  are  two  wire  repair  tasks 
(Session  1  and  Training  Session  2  from  the  F/A-l 8  test  data).  These  tasks  could  be 
designed  to  be  very  similar  not  only  in  time  but  in  content  as  well.  Within  each  task, 
various  cursor  movement  activities  could  be  forced  through  a  script.  The  cursor 
movement  activities  could  be  made  to  include  the  following: 

1 .  Moving  the  cursor  and  selecting  something  within  a  dialog  box. 

2.  Moving  the  cursor  and  selecting  an  item  within  a  menu. 

3.  Moving  the  cursor  and  selecting  radio  buttons  within  text. 

4.  Moving  the  cursor  and  selecting  check  boxes  within  text  screens. 

5.  Moving  the  cursor  and  selecting  graphic  diagnostic  blocks. 
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Within  each  task,  these  movement  activities  could  be  modified  or  added  to  (for 
the  particular  path  within  the  task)  as  time  permits  or  as  further  variations  are  identified. 
Identification  of  the  tasks,  paths  through  the  tasks,  and  the  list  of  movements  was  a  start 
for  the  AFIT  students.  The  purpose  was  to  assess  subjective  evaluations  and  time 
measures  to  determine,  respectively,  which  input  device  is  preferred  and  which  results  in 
faster  times  for  each  type  of  application. 

The  students  were  given  some  “rough”  scripts  of  the  wire  repair  sessions  which 
they  reviewed  carefully  to  identify  the  exact  path  and  cursor  movement  activities  to  be 
performed.  The  method  for  presenting  scripts  to  subjects  (e.g.,  verbal  or  written 
presentation)  was  also  determined  by  the  AFIT  students  prior  to  collecting  the  data. 

Lessons  Learned 

Results  of  the  AFIT  study  indicate  there  is  not  a  significant  difference  in  the  time 
required  to  perform  the  task  using  the  arrow  key  versus  the  thumb  knob;  however, 
qualitative  data  clearly  show  a  preference  for  the  arrow  keys  over  the  thumb  knob  (Streff 
&  Gundel,  1992).  Thus,  the  results  of  this  study  are  that  future  designs  should  rely  on 
arrow  keys  for  cursor  and  pointer  control. 

Additional  factors  must  be  considered  when  designing  an  input  device.  In 
particular,  the  flight  line  includes  environmental  factors  such  as  grease,  dirt,  sand,  and  the 
like.  Therefore,  a  track  ball  must  be  able  to  withstand  having  sand  blown  over  it,  in  it, 
and  so  forth.  Given  these  considerations,  a  limited  number  of  input  device  types  can  be 
considered.  Therefore,  until  “ruggedization”  of  input  devices  occurs,  the  arrow  keys 
remain  the  most  effective  means  of  moving  the  cursor  and  pointer. 

Prop 

The  prop  is  the  device  used  to  hold  a  PMA  upright  when  it  is  placed  on  a  flat 
surface. 

Phase  II 

The  PCMAS  I  prop  can  assume  five  different  positions  (evenly  positioned  within 
a  145°  angle).  In  one  position,  the  prop  can  be  used  as  a  handle.  This  prop,  a 
commercially  available  lab  equipment  handle  made  of  steel,  attaches  to  either  side  of  the 
case.  The  prop  can  be  released  from  the  case  by  pushing  both  sides  of  the  prop  toward 
the  case  (a  push-to-tum  handle/prop). 

The  prop  on  the  PCMAS  II  can  be  positioned  at  eleven  angles  (evenly  positioned 
within  a  300°  angle).  Like  PCMAS  I,  it  allows  the  user  to  carry  the  PCMAS  II  when 
using  the  prop  as  a  handle.  The  prop  is  a  commercially  available  lab  equipment  handle, 
made  of  plastic,  which  attaches  to  either  side  of  the  PMA  case.  The  prop  can  be  released 
from  the  case  by  simultaneously  pushing  two  buttons  located  on  the  prop/handle  sides  (a 
push-button-to-tum  handle/prop). 
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The  appropriate  height  of  the  F/A-18  PMA,  where  a  prop  is  used,  was  determined 
by  using  several  parameters.  The  goal  was  to  determine  the  height  that  provides 
maximum  visibility  for  the  5th  to  95th  percentile  body  measurements  for  United  States  Air 
Force  (USAF)  personnel,  looking  at  the  PMA  on  the  ground  or  on  a  table,  while  standing 
at  a  distance  of  three  to  five  feet.  A  secondary  concern  was  the  ability  to  position  the 
PMA  on  a  table  such  that  people  standing  around  the  table  would  be  able  to  view  the 
screen  contents  (e.g.,  for  demonstration  purposes).  Specific  information  for  each  of  these 
criteria  were  gathered  (USAF  personnel  height  [Van  Cott  &  Kinkade,  1972],  PMA 
Ovonics  screen  visual  angles,  etc.)  and  calculations  were  made  to  determine  the  prop 
angle  degrees  required  for  optimal  viewing  of  the  PMA. 

The  optimum  angle  between  the  PMA  and  the  ground  was  calculated  to  be  24°. 
This  angle  assumes  viewers  will  be  standing  and  observing  the  PMA  at  the  propped  angle 
either  on  the  ground  or  on  a  table.  When  using  this  dimension  to  design  props  in  the 
future,  designers  should  carefully  determine  the  actual  prop  height  using  the  dimensions 
of  the  individual  PMA  to  accommodate  this  angle. 

Lessons  Learned 

A  prop  should  be  designed  which  allows  the  PMA  screen  to  be  at  a  24°  angle  with 
respect  to  the  ground/table.  Additional  prop  angles  can  be  added  to  accommodate  various 
PMA  screen  positions. 


Straps  and  Handles 


Phase  II 

PCMAS  I  and  PCMAS  II  do  not  have  a  strap  for  carrying  purposes.  The  prop, 
when  in  the  parallel  position,  is  designed  to  be  used  as  a  hard,  fixed  handle  (thereby 
eliminating  the  need  for  a  carrying  strap). 

The  F/A-18  PMA  does  not  have  a  hard,  fixed  handle.  Instead,  it  has  a  strap  which 
could  accommodate  use  as  a  carrying  handle  or  a  long,  over-the-shoulder  strap.  The  strap 
on  the  PMA  is  designed  (e.g.,  length,  width,  clasps,  etc.)  using  information  found  during 
a  field  test  conducted  at  Edwards  AFB,  CA  (Applied  Science  Associates,  Inc.,  1990), 
MIL-S-40022E  (Department  of  Defense,  1985),  and  other  design  reference  sources  (Van 
Cott  &  Kinkade,  1972).  Strap  designs  should  include  the  following  features: 

1 .  Length  of  the  strap  should  be  approximately  3 ’8”.  This  will  accommodate  the 
95th  percentile  body  measurements  for  the  USAF  man  or  woman.  Personnel  at 
Edwards  indicated  that  the  long  strap  “allows  you  to  put  it  over  your  neck  and 
shoulder  and  slide  it  around  back  to  prevent  swinging.”  (For  example,  when 
carrying  the  PMA  to  the  flight  line,  it  could  be  positioned  on  the  back  to  prevent  it 
from  swinging  while  walking).  The  length  used  at  Edwards  varied  from  17”  to 

3’ 7”;  technicians  preferred  the  longer  strap  (they  also  wanted  the  ability  to  adjust 
the  strap  to  a  shorter  length). 

2.  The  width  of  the  strap  should  be  approximately  2”.  The  width  of  the  str  ap  used  at 
Edwards  was  15/16”  and  personnel  indicated  that  they  would  have  preferred  it  to 
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be  “...up  to  1”  wider....”  The  two-inch- wide  strap  will  accommodate  2.5th 
percentile  body  measurements  for  the  USAF  woman. 

3 .  The  necessity  for  a  shoulder  pad  on  the  strap  was  not  found  in  any  of  the  data 
searches  made. 

The  final  design  of  the  F/A-l  8  strap  allows  for  the  strap  to  be  folded  into  a  bi-fold 
(three  layers)  position  which  accommodates  a  handle-type  configuration.  When 
unfolded,  the  strap  also  accommodates  the  long,  over-the-shoulder,  configuration. 

Lessons  Learned 

The  key  to  design  of  handles  or  straps  is  to  (1)  permit  the  user  to  readily  pick  up 
the  device  (e.g.,  using  a  handle),  and  (2)  permit  the  user  to  carry  the  device  without  using 
any  hands  (e.g.,  using  an  over-the-shoulder  strap).  The  design  for  the  F/A-l 8  PMA 
served  both  of  these  functions  effectively. 

Battery/Power  Requirements 


Phase  II 

PCMAS  I  and  PCMAS  II  batteries  were  silver  zinc  batteries  —  one  battery  pack 
per  PCMAS  (approximately  22  battery  cells  per  pack).  The  batteries  are  rated  at  5  amp 
hours  (i.e.,  drained  at  5  amps,  it  will  last  for  1  hour).  Operating  voltage  for  a  battery  pack 
is  between  22  and  32  volts.  The  system  operates  at  approximately  27  watts;  therefore, 
each  battery  pack  provides  the  system  at  least  five  hours  of  operation. 

The  batteries  were  external  battery  packs  attached  to  the  PCMAS  I  and  II  through 

a  cable. 

The  F/A-l  8  PMA  uses  the  same  type  of  silver  zinc  batteries;  however  each  battery 
pack  consists  of  only  1 1  battery  cells  per  pack.  The  amp  hour  rating  is  the  same  (5  amp 
hours).  The  operating  voltage  for  each  battery  pack  is  1 1  to  16  volts.  The  system 
operates  at  approximately  17.55  watts,  thereby,  allowing  the  system  to  operate  at  least  3.8 
hours  per  battery  pack. 

Batteries  on  the  F/A-l 8  PMA  are  contained  in  a  battery  case  which  is  mounted  to 
the  PMA  case  as  an  integral  unit.  On  one  end,  the  battery  case  is  attached  by  a  connector; 
on  the  other  end,  it  is  connected  by  a  dovetail  slide  mount.  This  arrangement  allows  the 
battery  case  to  be  attached  and  detached  from  the  PMA  case  without  the  use  of  additional 
tools  (e.g.,  screwdriver). 

Phase  III 

The  GDES  F-16  batteries  use  nickel  cadmium  batteries.  These  batteries  were 
chosen  in  an  attempt  to  reduce  cost.  (Silver  zinc  batteries  are  $75.00  per  cell;  nickel 
cadmium  batteries  are  less  than  $7.00  per  cell.)  Each  battery  pack  on  the  GDES  F-16 
PMA  consists  of  six  battery  cells  per  pack.  The  batteries  are  rated  at  5  amp  hours. 
Operating  voltage  for  the  battery  pack  is  between  6.7  and  9.4  volts.  The  system  operates 
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at  approximately  9  watts;  therefore,  each  battery  pack  provides  the  system  at  least  two 
hours  of  operation. 

Six  batteries,  encased  in  shrink-wrap,  form  a  pack.  This  pack  is  placed  in  the 
battery  compartment  of  the  PM  A  (as  opposed  to  a  totally  detachable  compartment  or  case 
as  used  on  the  F/A-18  PMA).  The  battery  compartment  can  be  accessed  by  loosening 
eight  Southco  quick-release  fasteners.  The  fasteners  are  loosened  with  a  quarter  turn  of 
the  screws  that  hold  them  in  place. 

Lessons  Learned 

The  requirements  for  the  portable  battery/power  can  be  reduced  to  the  following 
list: 

•  Assure  the  batteries  can  be  readily  obtained  (i.e.,  no  special  design  or 
configuration  is  required).  For  example,  camcorder  batteries  would  be  good. 

•  Assure  the  batteries  are  lightweight. 

•  Assure  the  batteries  provide  several  hours  of  uninterrupted  power. 

•  Assure  the  battery  charger  provides  for  discharging  of  batteries  if  that  is  a 
desirable  feature  of  the  battery. 

•  Assure  batteries  are  quickly  and  easily  removed  without  the  use  of  any  tools. 

One  final  note  concerning  battery  configuration:  the  system,  as  a  whole,  should 
allow  for  a  “Hot  Swap”  of  batteries.  That  is,  while  the  system  is  on,  (1)  the  system  must 
be  able  to  notify  that  battery  power  is  low,  (2)  the  user  must  have  adequate  time  to 
replace  the  batteries,  and  (3)  the  battery  swap  should  be  possible  without  turning  off  the 
system  and  without  losing  any  data. 


Screens 


Touch  Screen  as  an  Option 

Examination  of  input  devices  has  commonly  led  to  the  question,  “What  type  of 
input  device  would  best  serve  technicians’  needs  with  a  PMA?”  The  following 
information  is  provided  as  an  initial  assessment  of  the  potential  application  of  a  touch 
screen  to  the  IMIS  environment. 

A  touch  screen  input  device  responds  to  inputs  created  when  the  user’s  finger 
touches  a  particular  area  of  the  display  screen.  The  user  navigates  through  the  system  by 
pointing  at  particular  areas  of  the  screen  to  make  selections.  A  typical  display  includes 
menu  items  enclosed  in  boxes  which  resemble  buttons.  The  user  “presses”  the  buttons 
that  will  lead  to  the  desired  information.  Because  of  this  direct  navigation  capability, 
touch  screens  are  quite  useful  in  menu  selection  tasks. 

The  primary  advantage  of  a  touch  screen  device  is  the  direct  relationship  between 
the  user’s  input  and  the  displayed  output.  There  is  direct  hand-eye  coordination  because 
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the  input  device  is  also  the  output  device.  The  result  of  this  direct  relationship  is  a  system 
that  provides  faster  response  times  and  is  easier  to  learn  than  some  other  interaction 
devices  (e.g.,  Karat,  McDonald,  &  Anderson,  1986).  Conversely,  indirect  pointing 
devices  (e.g.,  a  mouse,  thumb  knob,  or  graphic  tablet)  do  not  have  a  direct  relationship 
because  they  are  removed  from  the  display  (Greenstein  &  Amaut,  1987;  1988).  The 
PMA  cannot  support  all  input  devices  that  are  removed  from  the  display  (e.g.,  mouse  or 
graphic  tablet)  because  of  its  size  constraints;  however,  it  does  support  arrow  keys  (hard 
keys)  and  the  thumb  knob  (joystick-type  device). 

Another  advantage  of  the  touch  screen  is  that  users  do  not  need  to  memorize 
commands  (e.g.,  cursor  movement  schemes,  etc.)  because  all  valid  inputs  are  displayed 
on  the  screen.  Thus,  the  interface  is  easier  for  novices  to  use  and  reduces  the  amount  of 
training  required. 

The  primary  interface  for  the  PMA  is  menu-based  but  also  requires  the  selection 
of  small  items  in  graphic  displays.  A  touch  screen  would  be  very  beneficial  for  the  menu 
selection  type  tasks  (assuming  the  targets  or  selectable  regions  are  large  enough)  but 
would  not  be  adequate  for  fine  detailed  pointing  such  as  that  required  for  graphic 
component  selection.  This  problem  could  be  resolved  by  using  a  stylus  for  pointing 
instead  of  a  finger.  A  stylus  may  be  used  with  some  touch  screens  as  an  alternative  to 
touching  the  screen  with  the  finger.  However,  a  stylus  requires  a  pointing  gesture  that  is 
less  natural,  and  the  user  must  either  continuously  hold  the  stylus  or  pick  it  up  before 
each  use.  Furthermore,  maintenance  technicians  would  need  to  use  their  hands  to  make 
repairs  while  operating  the  PMA;  therefore,  they  would  not  be  able  to  hold  the  stylus  at 
all  times.  Consequently,  the  stylus  would  need  to  be  attached  securely  to  the  PMA  to 
reduce  the  chances  of  it  creating  any  foreign  object  damage  (FOD). 

Of  course,  there  are  disadvantages  associated  with  the  use  of  touch  screens.  One 
is  that  users  must  be  within  an  arm’s  reach  of  the  display.  This  will  not  be  a  problem 
with  the  PMA  because,  with  the  exception  of  voice  activation,  alternative  input  devices 
also  require  the  technician  to  be  an  arm’s  length  away.  However,  fatigue  may  occur  from 
the  continual  lifting  of  the  hand/arm  to  the  display.  Additionally,  during  use,  the  finger, 
hand,  or  arm  of  the  user  may  block  the  view  of  the  screen.  This  problem  is  inherent  to 
the  direct  relationship  devices  (e.g.,  touch  screens,  light  pens,  and  styluses)  (Greenstein  & 
Amaut,  1987;  1988). 

Another  disadvantage  is  that  some  overlays  that  cover  the  touch  screen  may 
become  scratched  easily.  Thus,  durability  is  important  in  PMA  design  considerations. 
Furthermore,  a  literature  review  by  Gould  et  al.  (1990)  provided  evidence  of  an  increase 
in  user  errors  when  a  touch  screen  is  used  (e.g.,  users  inadvertently  activate  the  wrong 
area). 

The  main  disadvantage  of  using  a  touch  screen  for  the  PMA  is  the  work 
environment.  The  PMA  was  designed  for  maintenance  technicians  to  use  while  repairing 
aircraft.  The  environment  in  which  these  technicians  work  is  not  very  clean.  For 
example,  the  technician  is  likely  to  come  in  contact  with  dirt,  grease,  and  various  fluids 
which  will  interfere  with  the  use  of  a  touch  screen.  Most  touch  screens  are  enclosed;  thus 
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the  concern  is  not  with  damaging  the  device,  but  with  decreasing  its  functionality.  If  the 
technician  touches  the  screen  with  dirty  hands,  the  substance  will  obscure  the  screen, 
making  the  display  more  difficult  to  read.  Additionally,  the  system  might  be 
inadvertently  activated  by  dirt  on  the  screen  (Greenstein  &  Amaut,  1987;  1988). 

A  stylus  could  be  used  to  avoid  touching  the  screen  with  dirty  hands,  but  the 
screen  would  still  respond  to  the  user’s  finger.  Therefore,  there  is  a  great  likelihood  that 
the  technician  will  be  tempted  to  use  a  dirty  finger  instead  of  the  stylus.  Also,  there  is  a 
concern  about  the  stylus  creating  FOD  in  the  aircraft.  To  avoid  this  potential  problem, 
the  stylus  could  be  attached  to  the  PMA  by  a  cord;  however,  this  would  reduce  usability 
further. 

With  the  exception  of  environmental  factors,  a  touch  screen  is  suitable  for  use 
with  the  PMA.  However,  problems  with  dirt  and  grease  have  such  a  high  likelihood  of 
occurring  that  the  touch  screen  is  an  impractical  device.  Therefore,  the  PMA  should 
NOT  use  a  touch  screen  as  its  input  device. 

Phases  II  and  III 

Information  about  various  characteristics  of  liquid  crystal  displays  (LCDs)  was 
required  for  screen  purchasing  criteria  and  design  review  criteria.  Three  screen  types 
were  reviewed  in  relation  to  specified  contrast  ratio,  viewing  angles,  resolution,  and 
wattage.  These  screens  are:  the  Ovonics  screens  (purchased  for  the  PCMAS II  and  used 
on  the  F/A-18  PMAs  and  PMA(x)s),  Epson  screens  (to  be  used  for  the  PMA  and 
PMA(x))  (Epson  America,  Inc.,  1991)  the  Kyocera  screens  (to  be  used  for  the  IMIS 
PMA)  (Kyocera,  1991). 

The  screen  data  suggest  that  PMA  use  may  be  limited  with  viewing  angles  of  only 
50°  (i.e.,  25°  from  the  midpoint  to  either  side  of  the  box).  In  other  words,  a  user  could  not 
stand  at  an  angle  of  more  than  25°  from  the  midpoint  of  the  screen  and  be  able  to  view  the 
screen  text.  However,  usability  tests  would  be  needed  to  provide  data  to  support  or  reject 
these  conclusions.  Notably,  oblique  viewing  angles  of  32°  off  center  are  at  the  outer 
limits  of  legibility  (Morrissey  &  Chu,  1988). 

Usability  tests  (and  performance  tests)  demonstrated  that  the  Ovonics  screens 
provide  excellent  display  qualities;  however,  their  cost  is  prohibitive.  The  Epson  and 
Kyocera  screens,  on  the  other  hand,  are  reasonably  priced.  Furthermore,  as  shown  in 
Table  2,  the  Epson  screens  and  the  Kyocera  screens  have  similar  contrast  ratios,  viewing 
angles,  and  resolutions;  however,  the  adequacy  of  these  features  is  in  question.  Because 
features  of  the  two  types  of  screens  are  so  similar,  it  was  suggested  that  a  human  factors 
group  conduct  usability  tests  to  determine  whether  either  or  both  screens  would  meet  the 
needs  of  the  IMIS  field  test. 

A  primary  problem  with  LCD  screens  is  glare.  However,  the  problem  is 
especially  noticeable  when  the  screen  is  used  in  direct  sunlight.  One  solution  to  this 
problem  is  glare  filters,  which  reduce  the  glare  associated  with  the  current  screens.  These 
optical  glare  filters  often  have  Velcro  fasteners  which  allow  them  to  be  easily  attached  or 
removed  from  the  screen.  The  filter  should  be  selected  carefully  to  ensure  the  appropriate 
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one  is  used.  If  the  proper  filter  is  used,  black  characters  will  actually  appear  blacker  on 
the  display  than  they  do  without  the  filter  (this  could  also  improve  the  contrast  ratio 
problem  identified  below).  Greenstein  &  Amaut  (1987)  state  that  if  touch  screens  are 
used,  layering  effects  and  viewing  angle  parallax  problems  with  filters  should  be 
considered. 


TABLE  2.  Screen  Specifications 


Manufacturer 

Ovonics 


Feature 


Specification 


Epson 


Kyocera 


Contrast  Ratio: 

20:1 

Viewing  Angle: 

110  degrees  side  to  side 
135  degrees  top  to  bottom 

Resolution: 

80  dots  per  inch 

Watts: 

3.5 

2.5  more  for  backlight 

Contrast  Ratio: 

9:1 

Viewing  Angle: 

40  degrees  side  to  side 

50  degrees  top  to  bottom 

Resolution: 

80  dots  per  inch 

Watts: 

0.4 

2  to  3  more  for  backlight 

Contrast  Ratio: 

8:1 

Viewing  Angle: 

50  degrees  side  to  side 

50  degrees  top  to  bottom 

Resolution: 

80  dots  per  inch 

Watts: 

0.6 

3.1  more  for  backlight 

Another  design  consideration  that  reduces  problems  associated  with  viewing 
angle  and  contrast  ratio  is  modification  of  the  font  used  for  presentation.  Two 
modifications  could  substantially  assist  in  the  ability  to  view  the  display.  The  first  step  is 
to  make  ah  text  bold,  shadowed,  or  double-pixel-width.  In  their  study,  Uphaus, 
Barthelemy,  and  Reising  (1990)  found  that  double-pixel- width  characters  substantially 
reduce  reading  errors  when  displays  are  degraded  (e.g.,  columns  or  rows  in  the  dot  matrix 
are  missing).  These  findings  could  have  applicability  to  other  types  of  display 
degradation  such  as  contrast  ratio.  The  second  step  is  to  enlarge  the  size  of  the  font.  This 
larger  font  size  should  be  in  accordance  with  latest  minimum  font  sizes  specified  in 
Military  Specification  -  Manuals,  Interactive  Electronic  Technical:  General  Content, 
Style,  Format,  and  User-Interaction  Requirements  (MIL  M  87268)  (Department  of 
Defense,  1992b).  (Viewing  distances  of  three  to  five  feet  require  a  minimum  font  size  of 
0.17  to  0.34  inches.) 
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Subsequent  evaluations  of  the  Kyocera  and  Epson  screens  showed  that,  when  used 
in  direct  sunlight,  the  screens  begin  to  black  out  after  15  minutes.  Some  manipulations 
produced  an  additional  ten  minutes  of  use  before  the  screens  become  completely 
unusable.  Thus,  all  PMA  screens  should  be  tested  in  hot,  direct  sunlight  for  the  complete 
duration  of  their  expected  use.  This  type  of  testing  will  assist  in  ensuring  that  the  screens 
meet  the  durability  requirements  of  the  maintenance  flight  line. 

Lessons  Learned 

Tests  conducted  in  ambient  sunlight  indicate  that  all  PMA  screens  should  be 
tested  in  hot,  direct  sunlight  for  the  complete  duration  of  their  expected  use.  These  tests 
also  showed  that  monochrome  screen  presentations  are  much  more  legible  than  color 
screen  presentations.  Therefore,  until  color  screen  contrast  improves,  monochrome 
presentations  are  recommended. 

As  for  other  specifications,  screens  that  can  accommodate  the  specifications  of  the 
Ovonics  screen  are  preferred  (see  Table  2).  These  screens,  although  extremely  expensive, 
adequately  meet  all  screen  requirements  for  adequate  viewing  in  a  flight  line  maintenance 
environment. 

DISPLAY  SCREEN  REGIONS  AND  RELATED  FUNCTIONS  —  LESSONS 

LEARNED 

The  remainder  of  this  document  will  not  separate  designs  and  lessons  learned  into 
specific  phases  of  work.  For  clarity  and  flow,  it  will  provide  lessons  learned  with 
examples  from  the  various  phases  of  work  performed. 

Cursor  Movement  and  Selection 


Tab  Groups 

Early  versions  of  the  IMIS  user  interface  (i.e.,  F/A-18  PMA  and  earlier)  did  not 
require  an  abundance  of  cursor  movement  among  objects  on  the  screen.  However,  as 
user  interfaces  have  evolved,  it  has  become  necessary  to  allow  the  user  to  toggle  among 
groups  of  objects  on  the  screen.  This  capability  is  characteristically  served  by  grouping 
on-screen  information  into  chunks  of  related  topics.  The  user  then  navigates  among  these 
screen  regions  with  the  tab  key  and  subsequently  uses  the  arrow  keys  to  select  or  interact 
with  items  in  a  given  region.  The  GDES  IMIS  and  subsequent  IPS  development  efforts 
have  incorporated  this  feature  into  the  design.  As  a  general  rule,  when  defining  tab 
groups,  similar  functions  should  be  grouped,  then  sequential  cycling  through  the  groups 
should  then  be  permitted  by  pressing  the  tab  key  specification  (Wampler  et  al.,  1993). 

Pointer  versus  Cursor  versus  Focus  versus  Default 

To  assure  appropriate  functionality,  clear  distinctions  must  be  made  among 
pointer,  cursor,  active  focus,  and  default  screen  items.  The  pointer  is  the  object  on  the 
screen  that  moves  when  the  mouse,  joystick,  or  trackball  is  “rolled”  (i.e.,  no  clicks  are 
associated  with  this  movement).  The  pointer  is  generally  represented  by  one  of  a  variety 
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of  shapes,  such  as  an  arrow  or  an  I-beam.  The  cursor  is  the  object  that  indicates  the 
location  of  keyboard  focus  in  an  active  region.  The  cursor  can  be  shown  in  a  variety  of 
shapes,  such  as  a  vertical  bar  or  a  highlighted  menu  item.  Several  areas  on  the  screen  can 
have  a  cursor;  however,  only  one  cursor  location  can  have  active  focus.  Active  focus 
refers  to  the  screen  region  in  which  user  commands  (i.e.,  typing  on  keyboard,  clicking 
mouse  button)  will  register.  For  example,  if  the  menu  bar  has  active  focus,  subsequent 
keystrokes  will  execute  the  associated  commands  corresponding  to  the  menu  bar.  Certain 
cues  are  provided  to  indicate  active  focus,  such  as  blinking  or  highlighting.  A  default 
screen  item  is  the  one  push  button,  in  a  series  of  push  buttons,  that  has  an  emphasized 
border.  If  the  push  button  has  a  default  border,  pressing  the  Enter  or  Return  key  will 
activate  that  push  button. 

For  example,  in  most  Microsoft  Windows  applications,  the  user  can  position  the 
pointer  on  a  dialog  box  push  button  and  click  the  mouse  to  activate  the  item. 
Alternatively,  the  user  can  press  the  tab  key  to  move  the  cursor  around  the  dialog  box. 
This  action  would  eventually  move  the  active  focus  onto  the  defaulted  push  button.  Once 
the  active  focus  is  on  the  desired  push  button,  the  user  can  then  press  Enter  or  Return  to 
activate  this  button. 

Differentiation  of  these  functions  is  critical  in  designing  user  interfaces. 
Duplicating  the  accessibility  of  items  permits  users  to  choose  a  method  most  appropriate 
for  their  application  and  does  not  limit  the  hardware  implementations  used  for  the 
maintenance  aid. 

The  F/A-18  presentation  system  does  not  provide  pointer  functionality,  and  cursor 
functionality  is  limited  in  that  it  is  always  tied  to  the  active  focus.  Defaults  are  provided, 
however,  they  are  permanently  fixed  (e.g.,  always  on  one  push  button).  This  limitation  in 
functionality  forces  users  to  interact  solely  with  the  keyboard  when  running  the  software 
(i.e.,  mouse  or  joystick  functionality  is  not  available). 

The  GDES  presentation  system,  as  built  for  the  IMIS  Field  Test  at  Luke  AFB, 
incorporated  a  cursor,  a  pointer,  active  focus,  and  defaults;  however,  the  UNIX 
environment,  rather  the  User  Interface  Builder  in  UNIX,  did  not  permit  appropriate 
implementation  of  these  functions.  These  implementation  problems  were  especially 
confounded  by  the  limited  number  of  keypad  keys  and  the  limited  thumb  knob 
capabilities.  Some  resulting  problems  were  difficult  to  anticipate  but  very  obvious  once 
implemented.  For  example,  if  a  dialog  box  appeared  in  a  location  not  directly  under  the 
pointer,  the  user  had  to  move  the  Pointer  over  the  dialog  box  (with  the  thumb  knob)  to 
accept  keypad  key  events.  However,  it  would  have  been  much  more  efficient  for  active 
focus  to  have  been  forced  into  the  dialog  box,  irrespective  of  the  pointer  location. 
Additionally,  the  user  should  not  be  required  to  move  from  one  input  device  (thumb 
knob)  to  the  other  (keypad).  Redundancy  of  functionality  should  have  been  permitted  so 
that  both  input  devices  worked  nearly  everywhere.  However,  designing  this  functionality 
into  the  software  as  an  afterthought  became  a  labor-intensive  design  requirement,  and 
many  corrections  were  not  possible.  The  key  to  success  in  this  intricate  design  area  is 
choosing  an  interface  building  tool  which  provides  this  functionality  and  a 
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designer/developer  who  pays  close  attention  to  these  implementation  requirements  up 
front  and  throughout  the  development. 

The  IPS  used  a  Microsoft  Windows  environment  for  development.  The  user 
interface  tool  (Visual  Basic,  Professional)  allowed  for  pointer,  cursor,  active  focus  and 
defaults.  Most  of  these  functions  were  built  in  the  Visual  Basic  application  (i.e.,  minimal 
development  was  required).  In  addition,  a  full-time  designer/developer  was  devoted  to 
addressing  the  details  of  the  user  interface,  including  fine-tuning  these  functions  to  work 
with  a  limited  keypad  and  mouse.  The  built-in  functionality  provided  by  this  system 
significantly  reduces  the  amount  of  time  required  to  make  the  user  interface  compatible 
with  other  IMIS  platforms,  such  as  an  eye-piece,  or  desktop  computer. 

When  a  screen  of  information  appears  in  the  IMIS  environment,  active  focus 
should  be  initially  positioned  in  the  upper  leftmost  tab  group  (and  the  upper  leftmost  item 
in  the  tab  group).  The  caveat  for  this  positioning  is  that  the  tab  group  must  contain  an 
item  that  can  receive  focus  (i.e.,  non-editable  fields  would  not  be  permitted  to  receive  the 
cursor).  If  the  upper  leftmost  tab  group  contained  a  non-editable  field,  focus  would  be 
placed  in  the  next  tab  group  (i.e.,  cycling  through  tab  groups  is  done  left  to  right,  then  top 
to  bottom).  This  method  of  focus  placement  has  been  incorporated  in  all  applications 
since  the  F/A-18  application,  and  has  worked  well  in  all  circumstances. 

Cursor  Movement  via  Number  Selection 

Moving  the  cursor  via  number  selection  simply  entails  using  number  keys  as 
menu  accelerators  (e.g.,  Alt  F  to  access  the  File  menu).  The  earliest  IMIS  system  to 
incorporate  selection  by  number  was  the  PCMAS  II.  In  this  method,  menus  could 
contain  any  number  of  items.  However,  to  accommodate  the  number  selection  feature,  a 
method  was  required  to  indicate  when  the  user  was  finished  typing  the  number  (e.g., 
when  the  user  pressed  “1”  was  the  entry  complete,  or  was  the  user  going  to  enter  another 
number  to  make  the  number  “12?”).  A  separator  key  (“.”)  was  used  to  indicate  the  user 
was  finished  typing  the  number.  After  design  and  test  of  this  method,  it  was  determined 
that  a  simpler  method  of  selection  by  the  numbers  was  required. 

In  their  study,  Carney  &  Quinto  (1993)  found  that  users  prefer  the  quick  access 
capabilities  of  the  number  keys  to  soft  key  activation  or  cursor  movement  activation  of 
menu  bar  items.  In  their  system,  menus  are  limited  to  nine  or  fewer  items,  and  the  user 
chooses  an  item  by  simply  pressing  a  corresponding  number.  In  the  Carney  and  Quinto 
method,  after  the  menu  bar  has  been  activated  by  pressing  a  “menu”  key,  the  number  keys 
became  “hot.”  As  the  user  presses  a  number,  the  corresponding  menu  item  is  highlighted 
and  activated  (e.g.,  the  corresponding  pull-down  menu  is  displayed).  This  method  of 
selection  by  number  has  been  designed  and  implemented  in  IMIS  applications  subsequent 
to  the  PCMAS  II  application.  Again,  the  limited  keypad  restricts  accelerator  keys  to 
number  keys.  Additionally,  all  menus  are  limited  to  no  more  than  nine  items.  Lists 
longer  than  nine  items  appear  in  a  list  box  instead  of  a  menu. 
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Autorepeat  versus  Key  Flushing 

In  some  cases,  when  the  user  moves  between  screens,  the  new  display  takes 
longer  to  draw  than  the  user  takes  to  press  the  next  key.  In  the  PCMAS  II  application,  the 
“Next”  key,  used  to  move  between  screens,  is  flushed  each  time  it  is  pressed  (e.g.,  only 
one  entry  is  permitted,  then  all  subsequent  key  presses  are  ignored  until  the  system  is 
finished  “drawing”). 

In  the  GDES  IMIS  application,  the  same  philosophy  is  used  to  flush  keystrokes 
when  moving  between  screens.  This  method  is  especially  useful  when  movement 
between  screens  is  slow. 

In  the  IPS  environment,  interscreen  movement  times  are  relatively  fast;  therefore, 
autorepeat  is  permitted  for  movement  between  screens.  This  permits  the  user  to  move 
more  readily  through  familiar  screens.  The  problem  associated  with  this  implementation 
is  that  the  user  can  “page”  through  warnings,  cautions,  notes,  and  defaulted  prompts 
without  having  adequate  time  to  see  the  information  being  presented  (i.e.,  the  system 
would  present  them  faster  than  the  person  could  perceive  them). 

There  is  a  method  of  accommodating  autorepeat  without  permitting  the  user  to 
miss  “vital”  information.  If  autorepeat  is  permitted  for  movement  between  screens,  a 
different  key  could  be  assigned  for  acceptance  of  screens  with  “vital”  information  (e.g., 
warnings,  cautions,  notes,  and  prompts).  For  example,  the  return  key  would  normally 
move  between  screens;  however,  movement  between  “vital”  screens  would  require 
pressing  some  other  key. 


Keypad  Functions 

The  functionality  of  backing  up  has  been  addressed  numerous  times  in  the 
laboratory  in  an  attempt  to  resolve  the  functionality  associated  with  this  key.  The  result 
is,  essentially,  a  continuous  “Undo.”  However,  if  the  user  has  branched  off  to  another 
functional  area  (e.g.,  calls  up  a  dialog  box  to  change  a  setting)  and  finishes  that  function 
(e.g.,  accepts  the  dialog  box),  the  backup  function  cannot  be  invoked  to  re-enter  the 
completed  function  (e.g.,  the  dialog  box).  This  seems  logical  but  can  be  tricky  when 
backup  is  used  to  present  technical  order  procedures. 

The  F/A-18  presentation  system  implemented  backup  in  the  above  manner  and 
was  well  accepted.  In  this  system,  pressing  the  Backup  function  presents  users  with  a 
message  informing  them  that  backing  up  the  system  will  “undo”  that  step.  Subsequent 
sequential  backup  keypresses  can  then  be  made  without  repeating  the  message.  Backup 
is  only  permitted  within  maintenance  procedures.  Once  a  procedure  is  complete,  the  user 
cannot  backup  into  that  procedure. 

The  GDES  IMIS  presentation  system  implemented  backup  in  a  similar  manner; 
however,  the  message  is  not  directed  toward  the  user.  Rather,  the  backup  message 
identifies  software  and  data  that  will  change  (these  messages  were  not  understood  by  the 
user). 
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Future  methods  of  backing  up  should  use  the  “Undo”  functionality.  Using  the 
term  Undo  rather  than  Backup  would  help  clarify  the  true  functionality,  thereby  reducing 
the  need  for  a  message  to  the  user. 

A  branch  back  function  has  been  envisioned  for  IMIS  but  has  never  been 
implemented  at  the  laboratory  level.  The  intent  is  that  if  users  branch  off  to  another 
series  of  information  (e.g.,  branch  from  procedural  information  to  theory  of  operations), 
there  should  be  a  hot-key  available  which  allows  them  to  branch  back  to  the  first  piece  of 
information  (e.g.,  the  procedural  information).  This  functionality  would  not  necessarily 
require  new  keys,  but  users  should  be  able  to  easily  move  between  several  screens  of 
secondary  information  or  branch  back  to  their  primary  work  at  any  time. 

On-Screen  Keyboard 

An  on-screen  keyboard  allows  a  user  to  input  alphabetical  information  onto  a 
display  screen  via  an  indirect  pointing  device  with  a  select  function  (e.g.,  a  mouse 
incorporating  a  point  and  click  action,  or  arrow  keys  with  a  select  key  incorporating  a 
move  and  select  action).  Using  an  on-screen  keyboard  (i.e.,  pointing  and  selecting 
various  regions  on  the  screen,  labeled  with  alphabetical  characters)  results  in  the  display 
of  the  corresponding  alphabetical  character. 

Armstrong  Laboratory  implemented  QWERTY-arranged  on-screen  keyboards  for 
the  F/A-18  and  the  GDES  IMIS  applications.  However,  there  were  many  discussions  as 
to  whether  a  QWERTY  or  alphabetical  arrangement  would  be  better  for  the  on-screen 
keyboard.  Therefore,  a  separate  study  (Quill,  1994;  Quill  &  Biers,  1993)  looked 
specifically  at  on-screen  keyboard  arrangements.  Overall,  the  results  of  this  study 
indicate  that  the  on-screen  QWERTY  arrangement  was  better  for  both  experienced  and 
non-experienced  typists. 

A  standard  QWERTY-style  arrangement  is  recommended  for  on-screen  keyboard 
arrangements,  regardless  of  whether  the  input  device  is  a  keyboard  or  a  mouse. 

Labels,  Titles,  Captions,  Headers,  Text,  and  Characters 
Labels,  Titles,  Captions,  Headers 

Alignment  and  capitalization  requirements  for  labels,  titles,  and  headers  have  been 
clarified  and  specified  in  two  documents  for  the  IMIS  applications  at  AL/HRG.  For  the 
F/A-18  presentation  system,  the  Common  User  Interface  Specification  (Moorman  & 

Quill,  1991)  was  used.  For  the  GDES  IMIS  presentation  system,  the  Human-Computer 
Interface  Specification  provided  additional  information  on  this  topic  (Wampler  et  al., 
1993). 

Both  specifications  answer  questions  concerning  labels,  titles,  captions,  headers, 
and  so  forth,  primarily  using  guidance  provided  by  Galitz  (1985).  Galitz  identifies  key 
issues  to  consider  when  designing  these  fields.  The  most  important  issue  is  to  make 
“identifiers”  distinguishable  from  the  rest  of  the  text.  This  may  be  accomplished  in 
several  ways:  (1)  make  identifiers  the  opposite  case  of  the  text  in  the  field  or  cell 
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(capitalization  or  non-capitalization  must  be  rigidly  enforced- for  identifiers  and  entries), 
(2)  position  the  identifier  differently  than  the  entry  (e.g.,  indent  the  entry  or  center  the 
identifier  above  the  column  of  table  cells),  or  (3)  use  a  unique  symbol  to  distinguish 
between  the  identifier  and  the  entry  (e.g.,  horizontal  and  vertical  lines,  thicker  than  the 
standard  line  width). 

Galitz  also  notes  that  three  spaces  should  be  left  between  cell  entries  in  a  table. 
Column  headers  should  be  centered  above  the  cell  entry,  and  captions  and  data  fields 
should  be  formed  into  columns.  For  example: 

NAME:  _ 

STREET:  _ 

CITY:  _ 

STATE:  _ 

ZIP:  _ 

COUNTRY:  _ 

To  differentiate  between  identifiers  and  cell  entries,  Galitz  recommends  that  one 
or  the  other  should  be  capitalized.  In  other  words,  if  identifiers  such  as  “Name”  and 
Street”  are  not  capitalized,  the  letters  filled  in  by  the  user  should  be  automatically 
capitalized.  Although  it  may  be  easier  to  differentiate  the  identifiers  in  some  way  other 
than  capitalization  (e.g.,  indentation  or  unique  symbol  such  as  a  line),  most  of  Galitz 
examples  of  identifiers  are  in  capital  letters. 

Finally,  Galitz  notes  that  rows  of  information  should  be  divided  by  some  kind  of 
separator  placed  approximately  every  five  lines  (e.g.,  a  horizontal  line  or  an  extra  space). 
This  display  technique  assists  in  guiding  the  viewers’  eyes  across  the  row  without  losing 
their  place. 

Characters  and  Background 

A  complex  issue  in  each  IMIS  development  effort  is  background  color,  the  color 
of  the  text  on  the  background,  and  various  methods  of  emphasizing  text  (reverse  video, 
bolding,  etc.).  To  emphasize  the  current  step  being  performed,  original  screen  designs 
bolded  the  text  on  the  step.  In  each  development  effort,  a  hardware  review  (especially 
when  viewed  outdoors)  revealed  that  all  text  needed  to  be  bold  to  increase  readability. 
Designs  were  then  modified  so  that  reverse  video  could  be  used  to  identify  the  current 
step.  During  the  GDES  IMIS  effort,  an  extensive  investigation  was  performed  on 
background  color  (light  versus  dark),  text  color  (light  versus  dark),  and  switching 
between  the  two  alternatives  (light  text  on  a  dark  background  and  dark  text  on  a  light 
background).  The  first  issue  dealt  with  whether  one  alternative  improved  reading 
performance  more  than  the  other  (e.g.,  was  reading  improved  by  having  light  text  on  dark 
background  or  vice  versa).  The  second  issue  dealt  with  special  considerations  in  using 
reverse  video  and  switching  between  the  two  alternatives. 

The  findings  of  the  investigation  revealed  that,  for  readability  of  characters  with 
respect  to  background  (i.e.,  light  characters  on  a  dark  background  versus  dark  characters 
on  a  light  background),  there  is  no  statistical  evidence  to  support  one  alternative  over  the 
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other  (Obome  &  Holton,  1988;  and  Cushman,  1986).  For  example,  Obome  and  Holton 
(1988)  found  no  significant  differences  in  performance  when  comparing  light  text  and 
dark  background  with  dark  text  and  a  light  background  on  screen.  However,  they  did 
find  significant  differences  in  subject  preferences.  (Notably  the  sample  size  used  in  the 
study  was  small).  Subjects  preferred  the  dark  text  on  a  light  background  to  light  text  on  a 
dark  background. 

Special  considerations  for  reverse  video  and  switching  between  light  text  on  a 
dark  background  and  dark  text  on  a  light  background  are  discussed  in  Galitz  (1985). 
These  considerations  are  as  follows: 

•  There  can  be  potential  problems  when  displaying  dark  text  on  a  light  background 
if  there  is  excessive  brightness  caused  by  the  emitted  light  from  the  electron  gun. 
(This  should  not  be  of  concern  when  using  an  LCD.) 

•  Light  from  a  display  tends  to  bleed  into  the  surrounding  area;  therefore,  if  the 
background  is  light  and  the  text  is  dark,  the  background  will  bleed  into  the  text. 
On  the  other  hand,  if  the  text  is  light  and  the  background  is  dark,  the  text  will 
bleed  into  the  background.  McCormick  and  Sanders  (1982)  termed  this 
irradiation.  Galitz  warns  that  if  character  size  and  resolution  are  inadequate,  the 
dark  characters  on  the  light  background  may  not  be  as  legible  as  the  alternative 
configuration  (i.e.,  light  characters  on  a  dark  background).  (This  may  be 
justification  for  having  text  presented  as  light  on  a  dark  background.) 

•  Flicker  also  becomes  a  concern  when  dark  characters  are  presented  on  a  light 
background.  Refresh  rates  should  be  increased  to  between  90  and  100  cycles  per 
second  to  eliminate  the  occurrence  of  perceived  flicker  on  the  screen.  For  light 
characters  on  a  dark  background,  the  refresh  rates  are  adequate  at  60  cycles  per 
second.  (Again,  this  may  be  additional  justification  for  having  text  presented  as 
light  on  a  dark  background.  Although  this  is  probably  less  apparent  on  LCD 
screens  than  cathode  ray  tube  (CRT)  screens,  the  effect  may  still  be  present.) 

•  When  presenting  some  information  as  dark  text  on  a  light  background  with  other 
information  as  light  text  on  a  dark  background,  allow  sufficient  margins  around 
the  fields  to  eliminate  any  legibility  degradations.  (In  the  IMIS  design,  sufficient 
step  separations  should  alleviate  this  potential  problem.) 

•  Avoid  making  displays  appear  to  have  a  crossword  puzzle  effect  (i.e.,  switching 
between  the  two  alternatives  too  often).  Careful  alignment  and  columnization 
rules  should  be  followed  to  minimize  this  effect. 


There  appears  to  be  no  empirical  evidence  to  support  the  notion  that  one  display 
arrangement  results  in  better  performance  than  the  other;  however,  there  may  be  some 
considerations  for  IMIS  in  perceived  clarity  of  characters,  flicker  effects,  and  border 
differentiation.  The  result  of  these  considerations  is  that  text  that  is  to  be  read,  should  be 
presented  as  light  on  a  dark  background.  Other  text  could  be  presented  in  reverse  video 
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(i.e.,  dark  text  on  a  light  background).  Additionally,  extra  design  considerations  need  to 
be  followed  when  switching  between  the  two  display  alternatives. 

Character  Size 

For  the  F/A-l  8  effort,  character  size  in  screen  designs  was  determined  based  on  a 
user  standing  between  three  and  six  feet  from  the  screen.  As  the  user  moves  further  from 
the  screen,  the  size  requirement  for  the  text  is  greater.  However,  due  to  the  limited  screen 
size  of  the  hardware,  tradeoffs  were  required  between:  (1)  what  could  be  read  at  a 
distance,  and  (2)  what  would  fit  on  the  screen.  In  the  GDES  application,  this  same 
philosophy  was  used.  In  both  applications,  the  tradeoffs  made  did  not  adequately  address 
readability  or  screen-space  availability.  Therefore,  in  the  IPS,  adjustments  were  made  for 
character  size  depending  on  the  function  being  performed.  That  is,  if  the  text  is  to  be  read 
at  a  distance  (e.g.,  procedures),  it  must  be  larger.  If  an  arm’s  length  is  required  to  interact 
with  the  information  (e.g.,  selection  from  a  list),  character  size  can  be  standard  CRT 
character  sizes.  This  compromise  has  worked  well  in  the  application. 

According  to  the  General  Content,  Style,  Format,  and  User  Interface  (GCSFUI) 
and  American  National  Standard  Institute/Human  Factors  Society  (ANSI/HFS)  100-1988 
publication  (Department  of  Defense,  1992b;  Human  Factors  Society,  Inc.,  1988),  a 
minimum  of  16  minutes  of  arc  and  a  maximum  of  24  minutes  of  arc,  with  optimal  being 
20  to  22  minutes  of  arc,  are  preferred  for  reading  tasks.  Salvendy  (1987)  cites  similar  arc 
minutes.  The  formula  for  specification  of  the  character  height  is  in  GCSFUI  (Department 
of  Defense,  1992b). 

The  formula  provided  in  GCSFUI  for  character  height  specification  can  only  by 
used  for  small  angles.  Under  these  conditions,  height  (h)  is  equal  to  the  angle  in  radians 
(0)  times  the  distance  (d)  (i.e.,  h  =  0  x  d).  In  the  character  height  formula,  the  minutes  of 
arc  must  be  converted  to  radians.  To  make  this  conversion,  minutes  of  arc  must  first  be 
converted  to  degrees  of  arc  (dividing  by  60),  then  degrees  of  arc  must  be  converted  to 
radians  (dividing  by  57.3).  Therefore,  the  character  height  formula  is:  character  h  = 
(minutes  of  arc  x  distance)  /  (57.3  x  60).  The  actual  character  heights  for  a  three-foot 
viewing  distance  should  be  as  follows: 

h  =  (16  min  of  arc  x  36  inches)  /  (57.3  x  60)  or  h  =  0.17  inches 
h  =  (20  min  of  arc  x  36  inches)  /  (57.3  x  60)  or  h  =  0.21  inches 
h  =  (22  min  of  arc  x  36  inches)  /  (57.3  x  60)  or  h  =  0.23  inches 


h  =  (24  min  of  arc  x  36  inches)  /  (57.3  x  60)  or  h  =  0.25  inches 


For  a  screen  which  is,  for  instance,  640  pixels  x  480  pixels,  these  would  equate  to 
13.6  pixels  as  a  minimum  character  height,  16.8  to  18.4  for  optimum,  and  20  for 
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maximum.  The  specific  font  chosen  would  have  to  use  these  pixel  height  requirements 
for  a  three-foot  viewing  distance. 

Screen  Layout  and  Density  of  Information 

Use  of  white  space  (space  not  used  by  characters,  objects,  or  other  screen 
symbols)  is  important  to  ensure  the  display  screen  is  not  cluttered  and  to  assist  in 
emphasizing  important  points  on  the  screen.  The  question  of  screen  density 
specifications  was  raised  with  respect  to  the  design  of  IMIS  screens.  The  following  data 
were  compiled  and  used  in  all  applications  since  the  F/A-18  presentation  system. 

The  question  of  screen  density  becomes  more  important  as  character  font  sizes 
increase  and  graphics  and  other  screen  displays  become  more  complex.  To  ensure 
“good”  screen  layout,  density  should  not  exceed  between  15  and  25  percent.  That  is,  a 
screen  of  text  should  not  exceed  75  to  80  words;  the  remainder  of  the  screen  should  be 
white  space.  As  graphics,  icons,  titles,  labels,  and  so  fourth  are  added  to  a  screen,  the 
number  of  words  decreases. 

This  density  specification  is  stated  in  the  Deficiencies  and  Recommendation 
Summary  for  the  F/A-18  Portable  Maintenance  Aid  (Quill,  1992a).  Use  of  white  space 
was  not  calculated  for  the  F/A-18  presentation  system;  however,  screen  density  was 
estimated  for  the  F/A-18  and  subsequent  applications. 

Selectable  Items 

Selectable  items  include  a  variety  of  “widgets”  or  screen  objects.  The  common 
denominator  among  these  widgets  is  that  the  user  can  click  on  them  or  press  the 
enter/retum  key  when  the  focus  is  on  them  to  initiate  some  action  (e.g.,  the  user  “selects” 
a  menu  item  and  a  dialog  box  appears). 

Selectable  Text  and  Graphics 

There  are  several  ways  to  present  information  (e.g.,  words  or  graphics)  which 
have  links  to  more  information  (e.g.,  hyperlinks).  The  method  used  to  show  these  links  in 
PCMAS  II  (F/A-18)  and  GDES  IMIS  is  a  rectangular  box  around  certain  selectable  items 
(e.g.,  graphic  captions  and  block  diagrams).  The  primary  problem  associated  with  this 
implementation  is  how  and  when  to  show  the  user  that  the  item  is  selectable  (i.e.,  When 
should  the  rectangular  box  become  visible?).  The  box  cannot  be  present  all  the  time;  for 
example,  if  pieces  of  text  in  a  paragraph  are  selectable,  the  box  will  interfere  with  the 
readability  of  the  text. 

However,  with  the  onset  of  icon  bars  and  context-sensitive  actuation  of  menu 
items,  a  method  of  link  marking,  first  introduced  by  Glushko  (1990),  can  be 
implemented.  In  a  modified  version  of  Glushko’s  concept,  appropriate  icons  become 
available  as  the  user  moves  the  cursor  or  pointer  around  the  screen  (over  the  selectable 
items).  This  shows  the  user  what  additional  information  is  available  for  different  types  of 
information  presented  on  the  screen.  This  method  has  not  been  implemented  on  any 
IMIS  systems,  however,  implementation  of  this  type  of  identifying  strategy  is  practicable. 
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Autoselect  Radio  Buttons 

Aside  from  menus  of  lists,  listed  items  can  be  designed  to  allow  a  single  choice  or 
multiple  choices.  A  single  choice  occurs  when  the  user  is  required  to  pick  only  one 
condition  which  meets  the  criteria.  For  example,  the  user  needs  to  choose  whether 
continuity  exists  between  two  points  (i.e.,  a  “Yes”  or  “No”  answer).  Radio  buttons  are 
typically  used  to  show  activation  of  the  item  “selected.”  A  multiple  choice  occurs  when 
the  user  is  required  to  pick  all  the  conditions  that  meet  the  criteria.  For  example,  the  user 
needs  to  identify  whether  the  condition  exists  for  the  front,  back,  or  both  seats  of  the  F- 16 
aircraft.  Check  boxes  are  typically  used  for  this  type  of  choice  to  show  activation  of  all 
of  the  “selected”  items. 

When  a  single  choice  (e.g.,  radio  button)  is  used  in  the  user  interface,  the  user 
should  be  able  to  move  the  cursor  with  the  arrow  keys  over  the  desired  item  and  the  focus 
should  automatically  move  with  the  cursor  (just  like  menus).  This  design  feature  reduces 
the  number  of  keystrokes  required  of  the  user.  When  this  feature  was  added  to  the  F/A- 
1 8  PMA  for  some  operational  checkouts,  as  many  as  20  keystrokes  were  eliminated  by 
incorporating  this  “autoselect”  capability.  In  the  GDES  system,  the  autoselect  feature 
was  added  for  most  user  interface  single-choice  options.  In  the  IPS,  autoselect  was 
implemented  for  all  single-choice  options. 

Menus 

Several  issues  which  must  be  addressed  during  menu  design  include  the 
following: 

•  How  should  the  menu  bar  be  activated  if  it  is  not  always  visible  (e.g.,  due  to  space 
limitations)?  Should  the  menu  bar  toggle  on  and  off?  This  might  be  a 
consideration  if  the  screen  is  small.  In  the  F/A-18  and  GDES  systems,  a  menu 
key  activates  the  main  menu.  In  the  IPS  system,  the  menu  is  available  between 
procedures  but  not  while  the  user  is  in  the  middle  of  a  procedure. 

•  When  can  the  menu  be  accessed,  and  what  items  can  be  accessed  (i.e.,  which  ones 
need  to  be  grayed  out  and  when  do  they  need  to  be  grayed  out)?  This  varies  and 
will  continue  to  vary  with  every  application. 

•  How  should  information  be  organized  on  the  menu  bar  (e.g.,  frequency  of  use, 
criticality  of  use,  alphabetically,  and  so  forth)?  This  order  has  been  used  for  all 
IMIS  designs,  but  determining  frequency,  criticality,  and  the  like  should  be  done 
systematically. 

•  Should  different  jobs  (e.g.,  technician  versus  a  supervisor)  have  different  menus, 
or  should  they  just  have  restricted  access  to  certain  menu  items?  The  GDES  IMIS 
system  was  the  first  to  have  different  types  of  users  accessing  functions  on  the 
system.  It  simply  restricts  access  to  certain  menu  items.  This  was  well  accepted, 
and  the  design  lends  itself  to  better  transfer  training  when  a  user  is  promoted  (i.e., 
they  know  where  some  of  the  functions  are  located  on  the  menu  bar). 
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•  What  should  specific  menu  items  be  named?  This  should  be  systematically 
determined.  However,  names  should  not  necessarily  be  based  on  what  the 
functions  are  called  currently,  but  rather  on  what  they  should  be  named. 

When  menu  functionality  is  required  outside  the  menu  bar,  two  widgets  may  be 
used:  (1)  single-choice  options  (radio  buttons  or  listers)  with  a  confirmation,  and  (2)  pop¬ 
up  menus.  In  many  instances,  these  two  widgets  appear  to  provide  the  same 
functionality;  however,  there  are  some  occasions  where  one  widget  should  be 
implemented  rather  than  the  other.  Identification  of  the  criteria  to  be  used  for  these 
different  occasions  was  necessary  in  IMIS  design  and  development  efforts. 

Identification  of  the  criteria  to  be  used  in  differentiating  between  when  to  use 
single-choice  options  (radio  buttons  or  listers)  with  a  confirmation  and  when  to  use  pop¬ 
up  menus  involved  several  steps.  The  first  step  was  to  research  existing  literature  on 
when  to  use  each  widget.  The  Motif  Style  Guide  (Open  Software  Foundation,  1989)  was 
used  as  the  primary  baseline.  From  this  baseline,  additional  criteria  were  added  to  assist 
in  identifying  when  to  use  each  type  of  widget.  This  list  is  intended  to  be  an  aid  in  the 
GDES  IMIS  design  process  but  is  not  an  all-inclusive  list  of  criteria.  The  following 
criteria  resulted  from  this  analysis. 

Single  Choice  Options 

with  Confirmation  Pop-Up  Menu 


No  more  than  six  items  No  more  than  nine  items 

(for  radio  buttons  only) 

More  than  nine  items 
(for  listers  only) 

More  space  available  Little  space  available 

Access  to  other  dialogs  required  If  number  of  options  changes  from  time  to 

time 

Confirmation  of  choice  required 


Feedback 

Feedback  to  the  user  refers  to  acknowledgment  that  the  system  has  received  input 
from  the  user  and  either  is  working  on  an  answer  or  has  no  response  to  give  (in  either 
case  feedback  is  required).  Issues  involved  with  feedback  include  cues  (e.g.,  visual  or 
auditory)  and  the  time  required  to  provide  the  cues.  In  accordance  with  research  on 
screen  response  times,  responses  to  key  presses  should  be  less  than  0.1  second  for  visual 
feedback  on  the  screen  (Wampler  et  al.,  1993).  If  the  key  press  naturally  results  in  some 
visual  feedback,  no  additional  cues  are  necessary.  If  feedback  is  not  immediate  (less  than 
0.1  second),  the  pointer  shape  should  change  (e.g.,  a  watch  icon  will  be  displayed).  If  a 
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key  is  inoperative,  there  should  be  some  visual  indication  that  the  key  is  inoperative. 
When  key  presses  display  a  new  screen,  the  image  should  be  refreshed  immediately.  If 
response  time  is  greater  than  five  seconds,  a  progress  indicator  should  be  displayed  (IBM 
Corporation,  1991).  Visual  cues  have  been  used  throughout  the  design  process  because 
of  high  noise  levels  in  flight  line  maintenance  environments. 

The  goals  of  each  IMIS  application,  including  those  in  Phase  I,  have  been  to 
provide  response  times  of  less  than  two  seconds  for  most  screens  and  ten  seconds  for 
complex  processes  (e.g.,  running  a  diagnostic  module).  However,  both  goals  have  only 
been  attained  in  the  IPS.  The  F/A-18  presentation  system  provided  response  times  of  less 
than  two  seconds  due  to  a  “look  ahead”  capability  in  the  system.  That  is,  as  the  user 
views  the  currently  presented  screen,  the  system  prepares  the  next  screen  for  presentation. 
The  IPS  did  not  require  this  “look  ahead”  capability  to  present  the  technical  data 
information  in  the  time  required  because  of  innovative  data  structures.  Additionally,  the 
diagnostic  module  in  the  IPS  also  performed  within  the  ten  second  limit  and  frequently 
performed  well  below  this  limit. 

When  system  response  times  are  greater  than  a  few  seconds,  the  user  should  be 
provided  a  progress  indicator.  Progress  indicators  should  be  displayed  to  the  user  when 
the  computer  will  take  “some  period  of  time”  to  generate  and/or  draw  the  next  screen  on 
the  display.  The  question  posed  was:  “What  is  that  period  of  time?”  An  IBM 
publication  (1991)  states  that  processes  which  require  more  than  five  seconds  to  finish 
should  display  some  type  of  indicator.  The  actual  progress  indicator  display  can  be  a 
percent  complete,  “4  out  of  10  files  copied”  type  display,  or  a  scale  showing  the  status. 

The  other  related  topic  was  whether  some  indication  is  required  for  operations  of 
five  seconds  or  less.  In  this  case,  having  the  pointer  change  to  a  “wait”  icon  would  be 
beneficial.  Also,  this  icon  should  have  some  movement  associated  with  it  to  indicate  to 
the  user  that  something  is  happening.  For  example,  the  icon  could  be  a  watch  and  the 
hands  on  the  watch  could  move.  When  this  visual  cue  is  used,  it  should  be  designed  so 
that  the  user  cannot  move  the  icon  off  the  screen  (i.e.,  it  should  be  visible  to  the  user  at  all 
times).  Both  the  F/A-18  and  GDES  systems  successfully  implemented  the  wait  icon  for 
most  of  the  operations  which  require  greater  than  two  seconds  to  perform;  however,  it 
was  not  made  permanently  visible.  For  operations  requiring  more  than  five  seconds  to 
perform,  the  IPS  implements  a  permanently  visible  progress  indicator. 

SOFTWARE  USER  INTERFACE  AND  TECHNICAL  DATA  PRESENTATION  — 

LESSONS  LEARNED 

Presentation  of  technical  data  can  be  grouped  into  two  main  areas.  The  first  is  the 
presentation  of  technical  order  data  (e.g.,  maintenance  procedures,  parts  information, 
troubleshooting  information,  and  descriptive  or  theory  information).  The  second  is  the 
presentation  of  technical  data  which  requires  additional  information  or  confirmation  of 
validity  from  the  user  (e.g.,  dialog-type  information).  Within  the  context  of  the  software 
user  interface,  each  group  will  be  discussed  independently.  Within  each  group,  interface 
issues  will  be  addressed  in  terms  of  a  checklist  of  considerations.  See  Appendix  A  for 
example  screens. 
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Presentation  of  Technical  Order  Data 

The  following  subsections  provide  design  recommendations  based  on  the  F/A-18, 
GDES,  and  other  IMIS  (F-22,  F-16,  etc.)  presentation  systems.  Identification  of  how 
each  application  has  implemented  input  conditions  and  steps  is  less  important  than  the 
justifications  for  the  resulting  design  recommendations.  Therefore,  the  following 
subsections  provide  recommendations  for  design  along  with  their  respective 
justifications.  Note,  however,  that  many  different  designs  have  been  tried  prior  to  these 
resulting  recommendations. 

Group  Procedure  Input  Conditions  Together 

Grouping  input  conditions  on  a  screen  (or  series  of  screens)  assists  in  giving  the 
status  of  a  task  (and  nested  task)  and  an  overall  notion  of  what  needs  to  be  accomplished 
prior  to  beginning  the  primary  task.  An  effective  interface  design  can  result  in  fewer 
required  keystrokes  (e.g.,  after  checking  off  a  required  condition,  the  input  focus  moves 
automatically  to  the  next  unchecked  condition).  Throughout  the  IMIS  development 
process,  several  methods  have  been  used  to  display  input  conditions  —  including  separate 
and  grouped  displays.  The  Human  Computer  Interface  Specification  (HCIS)  (Wampler  et 
al.,  1993)  outlines  a  method  which  combines  the  benefits  of  each  method  into  an  efficient 
display  methodology  (see  Appendix  A  for  examples).  This  method  was  used  exclusively 
in  the  IPS. 

Within  specific  input  conditions,  there  are  some  formatting  issues  which  assist  in 
grouping  information.  Grouping  information  aids  users  in  locating  information  and 
assimilating  more  of  the  information  presented  on  the  screen.  Aside  from  presenting  the 
title  of  the  information  (e.g.,  INPUT  CONDITIONS),  each  type  of  condition  should  be 
separately  labeled  (e.g.,  CONSUMABLES).  The  consumables  are  best  displayed  in  a 
tabular  format  with  each  category  represented  in  columns. 

Warnings,  Cautions,  and  Notes 

In  any  presentation  environment  (paper  or  electronic),  it  is  often  critical  that  the 
technician  be  alerted  to  the  present  condition;  however,  getting  the  user’s  attention  is 
different  depending  on  the  environment.  In  a  computer-based  environment,  attention- 
getting  displays  can  be  readily  developed,  but  paper  manuals  have  limited  methods 
available  to  catch  the  attention  of  the  reader.  Additionally,  the  contrast  of  characters  to 
background  is  much  better  in  paper  than  in  electronic  environments.  Therefore,  even  if 
the  method  of  presentation  is  exactly  the  same,  some  of  the  attention-getting 
characteristics  provided  by  good  contrast  are  not  as  effective  in  an  electronic 
environment. 

In  efforts  to  attract  the  user’s  attention  to  the  alerts,  various  icons  have  been  used, 
distinguishing  borders  have  been  used  among  the  alert  types,  and  explicit 
acknowledgments  are  used  for  each  alert.  For  example,  among  the  IMIS  displays 
implemented  throughout  development,  alerts  have  been  modal  dialogs  (not  allowing  any 
user  input  until  the  dialog  is  acknowledged)  appearing  prior  to  the  display  of  subsequent 
information. 
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Alerts  presented  prior  to  the  beginning  of  the  task  (e.g.,  procedural  alerts)  should 
be  distinguished  from  the  alerts  that  apply  to  only  one  step  (e.g.,  step  alerts). 

Additionally,  and  especially  if  presented  as  dialogs,  all  alerts  should  be  available  for 
review  after  initial  display.  The  IPS  IMIS  implementation  incorporates  an  icon  approach 
to  this  requirement.  Because  many  “windows”  applications  now  use  an  icon  bar  for 
“quick  access”  to  information,  recent  IMIS  designs  have  incorporated  an  area  at  the  top  of 
the  screen  (under  the  Title  Bar)  for  procedural  icons.  The  user  can  tab  to  this  area  and 
select  the  icon  (e.g.,  press  return)  to  redisplay  the  procedural  icon. 

Warnings,  cautions,  and  notes  which  apply  to  the  entire  task  need  to  be  shown 
prior  to  beginning  the  task.  Exact  placement  of  the  alert  has  generally  been  displayed 
after  required  conditions  are  met.  Alerts  which  pertain  to  a  particular  step  should  be 
displayed  adjacent  to  the  step  to  which  they  apply.  The  IPS  implementation  provides 
space  above  steps  for  the  procedural  icons  and  space  to  the  left  of  steps  for  the  step  icons. 
Warnings,  cautions,  and  notes  which  apply  to  the  entire  task  are  shown  prior  to  beginning 
the  task.  Finally,  Warnings,  cautions,  and  notes  applying  to  a  particular  step  are 
displayed  in  a  dialog  box  if  the  step  is  highlighted  as  the  currently  active  step. 

To  conserve  room  on  the  display  screen,  when  multiple  alerts  pertain  to  a  step  or  a 
procedure,  the  icons  should  be  stacked  on  top  of  one  another  with  the  most  important 
(e.g.,  warning  icon)  on  the  top.  Upon  selection  of  the  icon,  the  user  would  view  all  icons 
in  succession  starting  with  the  most  important  (e.g.,  warnings,  then  cautions,  then  notes). 
If  there  are  several  alerts  within  one  type  (e.g.,  two  warnings),  the  warnings  are  displayed 
in  the  order  they  are  authored. 

A  design  concept  under  consideration  is  to  allow  the  user  to  choose  specific  alerts 
to  be  redisplayed.  This  could  be  accomplished  through  display  of  a  selector  on  each  alert 
screen.  This  selector  would  show  the  total  number  of  alerts  to  be  displayed,  as  well  as  the 
number  of  the  current  alert  being  displayed.  The  user  could  then  explicitly  choose  the 
alert  desired  and  that  alert  would  be  redisplayed. 

Presentation  of  Steps 

A  point  paper  was  provided  to  Armstrong  Laboratory  from  the  F-22  Engine 
Support  Systems  Data  Manager  (1992).  This  paper  addressed  a  philosophy  of  the  IMIS 
systems  personnel  to  present  information  in  a  step-at-a-time  manner.  The  purpose  of  the 
paper  was  to  identify  that  a  screen-at-a-time  approach  could  provide  a  better  interface  for 
maintenance  technicians  than  a  one-step-at-a-time  approach.  The  point  paper  was 
reviewed  to  identify  any  covert  reasons  this  approach  could  not  be  used  in  an  F-22  IMIS 
environment.  The  following  comments  were  provided  to  Armstrong  Laboratory  for 
further  review. 

It  appears  that  a  proposed  screen-at-a-time  approach  will  work;  however,  some 
design  features  will  need  to  be  employed  to  meet  GCSFUI  requirements  (Department  of 
Defense,  1992b)  and  usability  requirements. 
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Requirements  would  include  the  need  for  a  NEXT  function  (Department  of 
Defense,  1992b)  key,  a  BACK  function  key,  a  TAB  function  key,  a  BACKTAB  function 
key,  arrow  key  functions,  and  a  pointer  function. 

The  NEXT  and  BACK  functions  would  be  used  to  move  between  screens  (as  they 
currently  do);  however,  in  this  new  application,  pressing  the  NEXT  function  key  would 
display  a  new  set  of  steps. 

The  TAB  and  BACKTAB  function  keys  would  move  the  cursor  among  tab 
groups  on  the  screen  (e.g.,  text  pane,  graphic  pane,  icon  area,  etc.).  The  text  pane  on  the 
screen  would  act  as  the  primary  tab  group  and  would  hold  a  “key”  as  to  which  graphic  is 
displayed  at  any  given  time.  For  example,  the  key  would  be  the  step  which  is  currently 
active.  The  graphic  displayed  would  correspond  to  the  step  currently  active.  The  TAB 
key  would  simply  move  from  the  currently  active  step  to  the  currently  active  graphic. 

The  arrow  keys  and  pointer  would  be  used  to  move  the  cursor  within  the  tab 
group  (e.g.,  from  step  to  step).  There  remains  a  question  here  about  how  to  handle 
selectable  words  within  a  step;  however,  making  the  step  number  selectable  might  solve 
this  dilemma.  In  other  words,  the  user  could  move  the  cursor  (via  arrow  keys  or  point- 
and-select)  onto  the  step  and,  subsequently,  the  graphic  would  change  to  match  the  step. 

The  user  could  simply  move  the  cursor  down  the  content  region  to  the  last  step 
displayed,  press  the  down  arrow  again  (through  the  steps  presented  on  the  screen  to  the 
bottom  step),  and  the  next  set  of  steps  would  be  displayed.  Again,  this  would  help 
promote  the  continuing  task  sequence  reinforcement  aspect  identified  in  the  point  paper. 
If,  on  the  other  hand,  the  user  presses  the  NEXT  function  key,  a  new  set  of  steps  would 
be  displayed  on  the  screen,  thereby  minimizing  keystrokes. 

In  relation  to  the  basic  concept  outlined  in  the  point  paper,  the  screen-at-a-time 
method  seems  reasonable  and  feasible  —  given  the  modifications  identified  above.  As 
the  user  moves  the  cursor  down  the  screen  onto  various  steps  (e.g.,  by  pressing  the  down 
arrow  key),  the  appropriate  graphics  are  displayed;  if  the  user  does  not  need  additional 
visual  information  (provided  by  the  graphics),  the  step  may  simply  be  read.  The  steps, 
however,  should  be  separated  by  appropriate  white  space  (i.e.,  perceptibly  more  carriage 
returns  between  steps  than  between  lines  of  continuous  text).  This  white  space  increases 
the  users’  ability  to  keep  their  place  when  moving  from  line  to  line. 

Presentation  of  Follow-On  Conditions 

Presentation  of  follow-on  conditions  and  presentation  of  required  conditions  raise 
many  of  the  same  issues.  For  example,  follow-on  conditions  should  be  presented  all  at 
once  (a  full  screen).  Fewer  keystrokes  are  required  if  they  are  presented  all  at  one  time. 
The  user  should  be  provided  three  options:  (1)  see  the  procedure  to  complete  the  follow- 
on  task,  (2)  check-off  the  follow-on  task  as  having  already  been  completed,  or 
(3)  postpone  the  follow-on  task  for  completion  at  a  later  time. 
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Graphics 

Presentation  of  graphics  has  a  whole  range  of  pertinent  topics  associated  with  it. 
This  discussion  is  intended  to  identify  these  topics  at  a  high  level. 

Graphics  associated  with  a  step  need  to  be  displayed  as  the  appropriate  step  is 
highlighted.  The  graphic  displays  the  appropriate  call-outs  for  the  highlighted  step 
(without  requiring  scrolling).  White  space  (i.e.,  border  areas  without  any  information) 
should  be  minimized.  These  modifications  can  be  made  during  authoring  of  the  technical 
data  or  at  display  time.  When  presented  on  a  computer  screen,  graphics  used  in 
presentation  of  technical  data  should  contain  much  less  detail  than  graphics  presented  on 
paper.  This  change  needs  to  be  made  during  authoring. 

Presentation  of  wiring  diagram  graphics  should  include  identification  of 
bulkheads,  names  of  line-replaceable  units  (LRUs),  plug/jack  labels,  and  pin/socket 
numbers.  Adding  this  type  of  information  to  wiring  diagrams  will  aid  technicians  in 
readily  locating  the  wire  that  needs  to  be  tested. 

Presentation  of  Other  Screen  Regions  in  Technical  Order  Data 

Message  Lines.  Message  lines  should  be  used  throughout  a  technical  data 
presentation  to  show  the  user  how  to  move  to  the  next  piece  of  pertinent  information  (i.e., 
the  next  screen  of  information). 

Softkeys.  The  softkeys,  generally  presented  at  the  bottom  of  the  screen,  allow 
quick  access  to  pertinent  menu  bar  actions  through  a  single  key  press  (e.g.,  “F10K”). 
The  pertinent  issue  for  softkeys  is  identification  of  the  appropriate  softkeys  for  the 
various  types  of  screens.  A  matrix  of  screen  types  and  potential  softkey  labels  is 
recommended  for  designing  and  implementing  these  functions.  The  matrix  should  result 
in  a  set  of  softkey  labels  given  the  limited  number  of  types  of  screens.  It  should  be  noted, 
however,  that  Carney  and  Quinto  (1993)  determined  that  use  of  softkeys  should  be 
minimized  in  future  designs  because  users  are  unfamiliar  with  these  keys. 

System  Subsystem  Subassembly  (SSS)  Browser.  There  are  two  overall  functions 
of  the  system  subsystem  subassembly  (SSS)  browser.  The  first  is  to  allow  users  to  view 
data  for  any  system  without  recording  that  action  as  having  been  performed.  For 
example,  users  may  want  to  view  a  procedure  before  performing  it  on  the  aircraft.  The 
browser  would  allow  this  function.  The  second  function  is  to  allow  users  to  access  data 
anywhere  in  the  system  and  to  record  that  actions  have  been  performed.  For  example,  the 
user  may  decide  to  perform  a  task  (on  the  aircraft)  which  is  not  recommended  by  a 
diagnostics  aid.  The  SSS  browser  would  allow  the  user  to  choose  any  desired  procedure 
from  a  lister. 

To  accommodate  the  functionality  requirements  of  the  SSS  browser,  it  is 
recommended  that  several  display  viewports  be  displayed  simultaneously.  For  example, 
upon  first  entering  the  SSS  browser,  one  viewport  would  provide  a  choice  list  for 
choosing  procedures,  theory,  parts,  and  so  forth;  one  would  be  the  systems,  subsystems, 
subassemblies  list;  and  another  viewport  would  be  available  for  listing  data.  Note  that 
upon  first  entering  this  lister,  the  currently  active  choice  should  be  the  system  or 
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subsystem  currently  being  worked  by  the  user  (e.g.,  if  the  Head-Up  Display  [HUD]  is 
being  replaced,  the  HUD  system  would  be  highlighted  in  the  lister).  After  the  user 
verifies  or  changes  the  desired  system,  the  data  type  (e.g.,  procedures)  can  be  selected. 
Upon  choosing  the  appropriate  data  from  the  list  (e.g.,  the  specific  procedure  to  be 
performed),  the  user  could  choose  (off  the  push  buttons)  to  either  view  or  browse  the 
procedure  (actions  would  not  be  recorded)  or  to  perform  the  procedure  (actions  would  be 
recorded  in  a  log  file  to  be  used  in  diagnostics  or  forms  completion  activities). 

The  key  to  providing  this  capability  is  ensuring  that  the  data  are  appropriately 
“tagged”  in  the  underlying  database.  If  data  tagging  schemes  do  not  include  any 
hierarchical  structuring  of  systems,  subsystems,  and  subassemblies,  this  type  of 
presentation  is  not  possible. 
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GLOSSARY,  ACRONYMS,  AND  ABBREVIATIONS 


AC 

AFB 

AFIT 

AL 

AL/HRG 

ANSI 

Autorepeat 

Autoselect 

Backlight 


CAMS 

CMAS 

FOD 

GCSFUI 

GDES 

HCIS 

HFS 

IETM 

IMIS 

IPS 

Key  flushing 


Keypad 


Keytop 

LCD 

Lister 

LRU 


Alternating  Current 
Air  Force  Base 

Air  Force  Institute  of  Technology 
Armstrong  Laboratory 

Armstrong  Laboratory,  Logistics  Research  Division 
American  National  Standard  Institute 

The  function  that  makes  the  activation  of  a  depressed  key  duplicate  over 
and  over. 

Screen  regions  at  first  display  that  require  user  input  be  highlighted  and 
ready  for  user  input  of  acceptance.  This  feature  minimizes  keystrokes. 

A  light  which  illuminates  behind  the  screen  region.  The  backlight  allows 
the  user  to  see  the  screen  in  dark  environments  and  increases  screen 
contrast. 

Core  Automated  Maintenance  System 
Computerized  Maintenance  Aiding  System 
Foreign  Object  Damage 

General  Content,  Style,  Format,  and  User  Interface 
General  Dynamics  Electronics  Systems 
Human  Computer  Interface  Specification 
Human  Factors  Society 
Interactive  Electronic  Technical  Manual 
Integrated  Maintenance  Information  System 
IETM  Presentation  System 

When  drawing  an  image  on  the  screen  takes  longer  than  the  time  to  input 
several  key  presses,  the  system  will  accept  only  one  key  press. 

The  hardware  keys  associated  with  a  Portable  Maintenance  Aid,  usually  a 
limited  number  of  keys  (as  opposed  to  the  full  QWERTY  keyboard). 

The  area  on  the  upper  portion  of  a  hardware  key.  This  is  the  area  where  a 
user  presses  the  key. 

Liquid  Crystal  Display 

A  region  on  the  screen  that  contains  a  listing  of  objects  of  similar  type. 
Line  Replaceable  Unit 
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GLOSSARY,  ACRONYMS,  AND  ABBREVIATIONS  (Continued) 


MIL-STD  Military  Standard 

PC  Personal  Computer 

PCMAS  Portable  Computer-Maintenance- Aiding  System 

PMA  Portable  Maintenance  Aid 

Push-buttons  Areas  on  the  screen  region  that  can  be  clicked  or  activated.  Activation  of  a 
push-button  causes  some  action  to  occur  (e.g.,  clicking  on  a  Cancel  push¬ 
button  will  cancel  a  dialog). 

RF  Radio  Frequency 

Selectable  A  screen  region  which  can  be  highlighted  by  the  user,  then  activated  in 
some  way. 

Softkeys  Programmable  keys  which  can  change  functionality  depending  on  the 

screen  content.  The  region  on  the  screen  which  labels  the  function  is 
termed  the  softkey  region. 

SSS  System  Subsystem  Subassembly 

Thumb  Knob  A  knurled  (concave)  button  that  acts  similarly  to  a  joystick. 

Trackball  A  round  input  device.  Although  the  device  is  stationary,  the  top  portion  of 
the  ball  can  be  rolled.  Rolling  the  ball  moves  the  pointer  in  a 
corresponding  manner  across  the  screen. 

USAF  United  States  Air  Force 


Viewports  Screen  regions  in  which  various  types  of  information  can  be  displayed. 
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APPENDIX  A:  EXAMPLE  SCREENS 


RIGHT  FORWARD  MULTIPLEX  MATRIX  ASSEMBLY  9476A2,  REMOVAL  [94-76-02]. 


RECOMMENDED  ACTION:  HUD  SYSTEM  HEALTH  TEST 


Logon 


Begin  Work  Order 


RECOMMENDED  ACTION:  CHECK  RT  FWD  MUX  HUD  DIGITAL  DATA  CKT 


Best  Actions 


PERSONNEL  RECOMMENDED: 


PERSONNEL  RECOMMENDED: 


ircraft  safe  for  maintenance 


CHECK  RT  FWD  MUX  HUD  DIGITAL  DATA  CKT 


□  Perform  HUD  operational  checkout. 


Best  Actions 


REPLACE  RT  FWD  MUX  MAT  ASSY,  9476A2 
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